=== Cepheus|Away is now known as Cepheus
=== gnomefreak76 is now known as gnomefreak
[01:12] <cody-somerville> hmm... when I try to bind to 'lp:~oem-solutions-releng/live-build/live-helper' I get 'bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~vcs-imports/live-helper/trunk/".'. :/
[01:17] <cody-somerville> I can't check it out either.
[01:17] <cody-somerville> I think it has something to do with the branch being stacked
[01:36] <wgrant> cody-somerville: Yeah, it's to do with stacking. Was the project renamed from live-helper to live-build recently?
[01:37] <cody-somerville> wgrant, yes
[01:37] <wgrant> cody-somerville: LP doesn't update the stacked-on location automatically yet.
[01:37] <wgrant> So, 'hitchhiker lp:~oem-solutions-releng/live-build/live-helper'
[01:37] <wgrant> 'edit .bzr/branch/branch.conf'
[01:38] <wgrant> Set the project in stacked_on_location correctly.
[01:38] <wgrant> Save and close.
[01:38] <cody-somerville> wgrant, and that has to happen on the branch on bazaar.launchpad.net?
[01:40] <wgrant> cody-somerville: Yes.
[01:40] <cody-somerville> wgrant, so I'll need to wait until a losa is available?
[01:41] <wgrant> cody-somerville: No. hitchhiker (or a plain SFTP client) will let you fix it yourself.
[01:42] <cody-somerville> wgrant, what will the path be?
[01:42] <wgrant> cody-somerville: .bzr/branch/branch.conf, as above.
[01:42] <cody-somerville> wgrant, yes but what will the path be to root the root of the branch?
[01:42] <wgrant> lp:~oem-solutions-releng/live-build/live-helper
[01:42] <wgrant> If you're using hitchhiker
[01:43] <cody-somerville> never heard of hitchhiker
[01:43] <wgrant> Otherwise sftp://username@bazaar.launchpad.net/~oem-solutions-releng/live-build/live-helper
[01:43] <wgrant> hitchhiker sits on top of bzrlib, and lets you edit the files making up a remote branch.
[01:44] <cody-somerville> sweet
[01:44] <wgrant> So it handles lp: aliases properly, and is a little more convenient for just editing files.
[01:48] <cody-somerville> wgrant, Could I also add append_revisions_only = True?
[01:49] <wgrant> cody-somerville: You could indeed.
[01:49] <wgrant> And I often think it should be the default.
=== Ursinha-afk is now known as Ursinha
[04:59] <eugenesan> I have 2 uploads stuck in "Waiting to build" status for 17 hours, what is wrong?
[05:00] <micahg> eugenesan: lack of PPA builders?
[05:01] <eugenesan> You think? Hmm, too bad...
=== Cepheus is now known as Cepheus|Away
[06:55] <bilalakhtar> Can someone please score up my recipe build ?
[06:57] <bilalakhtar> https://code.edge.launchpad.net/~ubuntu-sa/+recipe/qstream-daily-builds
[10:58] <ta_bu_shi_da_yu> hi folks, I have recompiled the firefox source package and removed compiler optimizations to make it easier to debug segfaults.... can I upload this to my PPA or is this forbidden?
=== Cepheus|Away is now known as Cepheus
=== Cepheus is now known as Cepheus|Away
=== Cepheus|Away is now known as Cepheus
[12:25] <shadeslayer> while uploading via SFTP to ninja ppa, i dont get the amount of data uploaded.. any ideas why?
[12:25] <shadeslayer> errr
[12:25] <shadeslayer> s/ninja/
[12:52] <eugenesan> Hi all, I see 3 idle builders for both i386 and amd64, while my 2 uploads are stuck for 25 hours, any ideas why?
[12:55] <wgrant> eugenesan: It generally just means that the next job is being dispatched.
[12:56] <eugenesan> Looks like I was looking at official builders. PPA builders are in bad shape, amd64 is cchilling while i386 has 3 days que..why not uniting amd64 and i386?
[12:57] <wgrant> Mostly because I haven't quite finished the code yet.
[12:57] <wgrant> (seriously; I've got most of it done)
[12:59] <eugenesan> wgrant: Great! But how this dis-balance was created? Few i386 died? :-)
[13:00] <wgrant> eugenesan: Most of the i386 and amd64 builders are currently performing maverick alpha 3 testing.
[13:00] <wgrant> I don't know why it's so unbalanced, though.
[13:01] <eugenesan> I see
[13:03] <eugenesan> BTW, recently I've asked for armel PPA, and my request was declined, but I see 2 armel ppa-builders in idle, are they reserved for special purposes?
[13:03] <wgrant> There's no good ARM virtualisation system at the moment.
[13:04] <wgrant> So it's impossible to have builders that are both secure and not terribly slow.
[13:04] <wgrant> In this case, they are not secure, so they're usable only for Canonical projects, I believe.
[13:04] <eugenesan> you mean those builders are emulated?
[13:04] <wgrant> The armel ones are real hardware. The i386/amd64/lpia ones are VMs.
[13:08] <eugenesan> wgrant: I see, thanks for explanations.
[13:10] <wgrant> eugenesan: Maybe one day there'll be a good ARM virtualisation technology, and faster ARM hardware, and then we can have armel for everyone. But not for a while yet, I suspect
[13:14] <eugenesan> wgrant: I suppose LXC could work, openvz known to work either. And speed is about to be improved in next months.
[16:04] <hicham> can i host a fedora repository in launchpad ?
[16:10] <jelmer> hicham: Do you mean a RPM repository or a Fedora-related Bazaar repository?
[16:10] <jelmer> hicham: The latter is possible, the first is not possible at the moment.
[16:10] <hicham> jelmer: i meant the latter, thanks
[16:11] <hicham> jelmer: oh, sorry, i meant the first, ie an rpm repository
[16:12] <hicham> jelmer: thanks for answering :)
[17:35] <fale> hi
[17:36] <fale> is there a page describing advantages and costs of 'private' accounts (I read this in the soyuz point page, where 'private' ppas have +10000 points)
[17:50] <bdrung_> i change change the status for merge request that target ubuntu/<package>, but i can't change the status for merge request that target ubuntu/<series>/<package>. is this a bug? if yes, against which project should i file the bug?
[17:59] <antoinevg> I've been waiting about two days now for i386 builds in my PPA - is there a problem w/ the build servers?  https://launchpad.net/~antoine-7degrees/+archive/ppa/+build/1899057  https://launchpad.net/~antoine-7degrees/+archive/ppa/+build/1899037
[18:39] <jeremiah> Hi :)
[18:39] <abhijit> :)
[18:39] <jeremiah> I'd like to know if I can replicate the ARM v7 build toolchain
[18:40] <jeremiah> From what I understand, Ubuntu builds ARM v7 packages using sbuild
[18:41] <jeremiah> So I assume Ubuntu is using a pretty straightfoward build toolchain from debian
[18:42] <jeremiah> Perl haps there are some binary blobs and stuff, but mostly it is just off the shelf, correct?
[18:42] <jeremiah> If so, I'd loke to set something like that up myself.
[18:42] <jeremiah> Either to build packages for debian, i.e. be a porter, or to build them for our own use.
[18:43] <jeremiah> Our in this instance being GENIVI
[18:46] <jeremiah> https://answers.launchpad.net/launchpad/+question/118326
[18:46] <jeremiah> ^^ perhaps that will answer my questions
[19:45] <thopiekar> hi..
[19:45] <thopiekar> I want to add a branch on launchpad.. and it says that the location will be ~canola/+junk/canola-ubuntuone - how can it add it without a +junk
[19:45] <thopiekar> ?
[19:46] <micahg> thopiekar: ~you/project/branch-name
[19:47] <thopiekar> aah and when I'm not the owner of the project I'll get this location: ~canola/+junk/canola-ubuntuone ?
[19:48] <micahg> thopiekar: no, +junk is meant for stuff w/out a project
[19:48] <micahg> thopiekar: any branch under ~you is yours
[19:48] <thopiekar> ahh k
[19:49] <jcastro> "junk" means "branch not associated with a project" basically. It's not a good name
[19:50] <micahg> jcastro: maybe file a bug to change +junk to +misc?
[20:16] <thopiekar> problem here importing a git repo: http://pastebin.com/pFuW7FLD
[20:16] <thopiekar> my fault?
[20:20] <jelmer> thopiekar: imports over http are broken at the moment, the next release of launchpad will fix that.
[20:21] <thopiekar> oki
[20:21] <thopiekar> thanks
[20:21] <jcastro> micahg: there's a longstanding bug to rename it, the # escapes me
[20:22] <jelmer> thopiekar: Some of the imports you've registered also seem to be for URLs that are not accessible:
[20:22] <jelmer> e.g. https://git.code.openbossa.org/canola/mainline.git
[20:22] <thopiekar> sure?
[20:23] <thopiekar> git clone git://code.openbossa.org/canola/mainline.git works
[20:23] <jelmer> accessing that URL in my browser I get "You don't have permission to access /canola/mainline.git/ on this server."
=== fta_ is now known as fta
[20:24] <jelmer> thopiekar: in that case, please specify that URL in the import rather than the http one
[20:24] <thopiekar> kk
[20:25] <ion> jelmer: Git would start with https://git.code.openbossa.org/canola/mainline.git/info/refs
[20:25] <ion> But yeah, always better to use git:// instead of http(s).
[20:25] <thopiekar> oh no, I need to remove all the branches again and reimport them -> https://code.launchpad.net/canola
[20:25] <thopiekar> :|
[20:25] <jelmer> thopiekar: you should be able to just update the URLs
[20:26] <thopiekar> no way :{
[20:27] <jelmer> e.g. https://code.edge.launchpad.net/~canola/canola/canola-im
[20:28] <thopiekar> how do you changed that?
[20:28] <jelmer> "Change details" allows you to change it I think
[20:29] <thopiekar> Got here: Change branch details, Set branch reviewer and Edit whiteboard
[20:29] <thopiekar> but there is no way to change the url
[20:29] <thopiekar> :|
[20:32] <jelmer> thopiekar: I can update those URLs for you if you give me the Launchpad branch page URLs.
[20:33] <thopiekar> ok
[20:34] <thopiekar> send you the links
[20:35] <thopiekar> thank you for helping me and saving time!
[20:36] <thopiekar> great! thanks again!
[20:37] <jelmer> No problem :-)
=== fta_ is now known as fta
=== fta_ is now known as fta
[22:30] <crimsun> guh?  OOPS-1674ED4071
[22:30] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1674ED4071
[22:32] <wgrant> crimsun: What were you doing?
[22:33] <thumper> crimsun: it seems that our oops tools are barfing while I try and look at that error
[22:34] <james_w> I can see it
[22:34] <james_w> it's odd though
[22:35] <crimsun> I was trying to load bug 156085
[22:35] <ubot5> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/156085)
[22:35] <crimsun> (on edge)
[22:36] <james_w> SQL time: 6553 ms Non-sql time: 8369 ms
[22:36] <wgrant> Ow.
[22:37] <james_w> nothing particularly jumps out, although it seems to be doing a lot of single queries in the tales
[22:38] <james_w> it gets killed while working out which sprite to show for each subscriber
[22:38] <wgrant> That's interesting, since subscriber lists are loaded by AJAX now.
[22:39] <james_w> it got linked to bug 607879, but that doesn't sound right
[22:39] <ubot5> Launchpad bug 607879 in Launchpad Registry "https://bugs.edge.launchpad.net/~person/+participation timeouts (affected: 1, heat: 10)" [High,Triaged] https://launchpad.net/bugs/607879
[22:41] <james_w> ah, it's not the subscriber, it's the commenter
=== yofel_ is now known as yofel
[22:42] <james_w> it does look to be doing a query for every subscriber or something though
[22:46] <james_w> it needs someone with more smarts than me to look at it though.
[22:50] <mwhudson> it could be something for every comment?
[22:50] <mwhudson> it's a big old bug, lots of comments, lots of subscribers
[22:50] <mwhudson> lots of targets
[23:09] <lifeless> moving stuff thats slow to ajax just makes it more slow :P
[23:10] <wgrant> lifeless: Yes, but it means they can defer fixing things by splitting it across multiple requests...
[23:15] <MTecknology> Start 2010-08-04 (2505)   *blink*
[23:16] <lifeless> wgrant: doing repetitive work, with more roundtrips. \o/
[23:18] <wgrant> lifeless: The point was to make it non-repetetive.
[23:20] <MTecknology> i386  4   975 jobs (four days)
[23:20] <lifeless> wgrant: got to repeat all the work up to the context point before you can do the fragment handling
[23:20] <lifeless> wgrant: so its very much repetitive when you look at the appserver's effort
[23:21] <wgrant> lifeless: True, but if that time's significant then we have bigger problems.
[23:21] <wgrant> MTecknology: Oh, haven't seen it up at four days for a while.
[23:21] <lifeless> we have bigger problems
[23:21] <lifeless> wgrant: I love AJAX, its just not an appropriate fix for 'full page load is slow'
[23:22] <micahg> +distrotask is timeout-o-matic on edge AFAICT
[23:22] <wgrant> lifeless: Maybe not since you came along, but it was considered as the ultimate solution to that before.
[23:22] <lifeless> wgrant: did it work?
[23:22] <wgrant> (yes, I agree it sucks)
[23:22] <wgrant> It was somewhat effective, yes.
[23:22] <lifeless> mmm
[23:22] <lifeless> anyhoo
[23:23] <lifeless> micahg: url please
[23:23] <lifeless> micahg: did you get an OOPS code ?
[23:23] <micahg> lifeless: yeah, but I went past it since I knew there was a bug filed, I guess I should've recorded it
[23:24] <micahg> lifeless: would the time help?
[23:25] <lifeless> no, we don't have good query mechansisms for oops
[23:25] <micahg> lifeless: k, if I need another one, I'll record it