[00:01] <lamont> and if anyone ever expresses a belief to you that launchpad rollout changes launchpad-buildd?  please help them understand the reality of it all.
[00:01] <wgrant> I think everyone should know that by now.
[00:01] <wgrant> But perhaps I am wrong.
[00:01] <lamont> some people found out today
[00:02] <lamont> or maybe yesterday
[00:02] <wgrant> But yes, that UNKNOWNBUILDER diff is sane.
[00:02] <wgrant> https://code.edge.launchpad.net/~henninge/launchpad/bug-581746-serialization-error is the branch.
[00:03] <wgrant> Nothing interprets the value master-side.
[00:04] <wgrant> It's going to completely break some stuff if we ever get into a state where UNKNOWNBUILDER appears in production, but that was already the case, so this will only help with debugging.
[00:05] <lamont> wgrant: ok then.  that tells me that what I deployed on dogfood is newer-than-his for everything he cares about
[00:06] <wgrant> Yes.
[00:26] <DBO> I am getting permission denied errors on my branches, something going on?
[00:43] <courpse> Got a msg saying there wasa problem connectiong to the launchpad server.
[00:44] <courpse> Says to report here.
[00:57] <pifantastic> Anyone else getting a Permission denied (publickey) error when updating/committing from lp?
[00:57] <pifantastic> Happening to everyone at our office right now
[00:57] <bitmonk> yep
[00:57] <pifantastic> Ah
[00:57] <pifantastic> :(
[00:58]  * bitmonk seconds that
[00:58] <beuno> looking into it
[01:08] <donri> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[01:08] <donri> Trying to push.
[01:09] <mwhudson> donri: yes, working on it
[01:09] <donri> Thanks.
[01:19] <mwhudson> donri: back up now
[01:19] <mwhudson> pifantastic: back up now
[01:19] <donri> Thanks
[01:19] <pifantastic> Awesome, thanks mwhudson
[01:19] <mwhudson> DBO: for you too
[01:20] <DBO> mwhudson, I award you 10 internets
=== Ursinha is now known as Ursinha-afk
=== maco is now known as maco2
=== maco2 is now known as maco
=== lifeless_ is now known as lifeless
=== noodles775 changed the topic of #launchpad to: http://launchpad.net/ | Read https://help.launchpad.net/ for help | Help contact: noodles775 | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
=== mrevell is now known as mrevell-lunch
=== jelmer is now known as Guest38382
[12:51] <ochosi> hi, i have a question regarding versioning. i'd like to provide a package for more than one version of ubuntu, how does that work? (googled around but couldn't find the answer)
[12:52] <ochosi> is it as simple as removing the "lucid" in debian/changelog?
[12:55] <noodles775> Hi ochosi, the Versioning section at https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage  has some info.
[12:57] <ochosi> noodles775, hm, had already looked there before but it seems i didn't see the important part
[12:57] <ochosi> noodles775, thx
[12:57] <noodles775> It explains there the procedure for (1) when you don't need to recompile (easier), (2) when you do need to recompile (currently a bit more of a pain).
[12:57] <noodles775> Great.
[12:58] <ochosi> i need (1)
[12:58] <noodles775> OK, just make sure you upload it first to the oldest series, and then copy it (with binaries) to the newer series.
[12:58] <ochosi> ah right
[12:59] <ochosi> i uploaded my packages for lucid first...
[12:59] <ochosi> so next time i guess i'll build them in karmic, right?
[12:59] <ochosi> one more thing about debian/changelog: what version do i put there?
[12:59] <ochosi> version == distribution version
[13:00] <noodles775> whatever you upload to (ie. karmic)
[13:00] <noodles775> (that determines the initial publishing)
[13:01] <ochosi> ok, but if users in lucid install the package they could theoretically see that the package was initially built for karmic, no?
[13:02] <ochosi> because the changelog wouldn't be updated
[13:03] <noodles775> Yep.
[13:06] <ochosi> nevermind, i guess it doesn't really matter :)
[13:06] <ochosi> thanks noodles775
=== dcoles_ is now known as dcoles
=== Guest38382 is now known as jelmer
[13:09] <noodles775> q jelmer
[13:09] <noodles775> grr...
[13:09] <jelmer> hi noodles775 :-)
=== mrevell-lunch is now known as mrevell
=== Ursinha-afk is now known as Ursinha
=== mhall119_ is now known as mhall119
[14:25] <mdeslaur> so...how come when I look here: https://launchpad.net/~ubuntu-security/+patches?orderby=status
[14:25] <mdeslaur> bug 130099 status is "New" but in the bug itself, it's "Won't fix"
[14:25] <ubot5> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/130099)
[14:25] <mdeslaur> is it tracking "New" from the debian bug?
[14:25] <ccheney> anyone else having problems with LP oopsing a lot this morning?
[14:26] <ccheney> (Error ID: OOPS-1601O2043)
[14:26] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1601O2043
[14:27] <mdeslaur> ccheney: yeah, I'm getting OOPSes this morning also
[14:27] <ccheney> mdeslaur: ok
[14:29]  * deryck looks at the OOPS report
[14:30] <ccheney> deryck: it looks like i can generate them at will if you need another report
[14:31] <deryck> ccheney, nah.  Just waiting on that one to appear.
[14:32] <noodles775> mdeslaur: yeah, it's probably getting the status of the first bug-target.
[14:32] <mdeslaur> noodles775: that's not good :(
[14:32] <noodles775> mdeslaur: I haven't checked the code... deryck might know off hand (being a bugs person :) ).
[14:33] <deryck> mdeslaur, noodles775, yeah was typing.... just typing slow. :-) the patches view is using the default bugtask, in this case debian.  Does this really cause a problem?
[14:34] <mdeslaur> deryck: well, it makes the query kind of useless as most of the results are already released, invalid, or won't fix
[14:34] <wgrant_> Don't you really want an advanced search in Ubuntu's patches view?
[14:35] <mdeslaur> wgrant_: yeah, that would be better
[14:36] <mistrynitesh> getting a
[14:36] <mistrynitesh> sorry
[14:36] <deryck> mdeslaur, I guess, too, it's a question of if one task is closed should the bug still be listed as open in the +patches view, too.
[14:36] <mistrynitesh> getting a 'Timeout error' when changing status of a bug
[14:37] <deryck> mistrynitesh, I suspect this is gmb's fault ;)
[14:37] <mistrynitesh> Error ID: OOPS-1601N2057
[14:37] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1601N2057
[14:37] <deryck> gmb, ^^ related to heat queries perhaps?
[14:37] <mdeslaur> deryck: I think when the ubuntu tasks are all closed, the bug shouldn't be listed as open any longer
[14:38] <deryck> mdeslaur, right, but as a generic team view of patches, how do we work out that you only care about ubuntu-related bugtasks, since the view is on the bug, not the task level?
[14:39] <deryck> granted the team has "ubuntu" in the name :-)  but to make this generically work, it's a bit trickier, I think.
[14:40] <mdeslaur> deryck: I don't know how this should be resolved. All I know is I would like to see which bugs that are open for ubuntu that the team is subscribed to that have patches.
[14:40] <gmb> deryck, Hmm. Not sure. Looking now.
[14:41] <gmb> deryck, Though, probably, come to think of it.
[14:41] <deryck> gmb, lots of timeouts in the last few minutes with bug activity.  Perhaps those queries transactions were locking out other activity?
[14:41] <gmb> deryck, Hmm. Possible. Should be passed now.
[14:42] <gmb> mistrynitesh, Can you try updating the status of the bug again please?
[14:42] <gmb> The problem should hopefully have passed by now.
[14:42] <mistrynitesh> gmb: did it just a moment ago, still the same
[14:42] <deryck> mdeslaur, yeah, so I think in that case a query against ubuntu is better as wgrant_ notes.
[14:42] <gmb> Hmm...
[14:42] <deryck> thought I'm keen to have +patches view be as generically useful as possible.
[14:44] <gmb> mistrynitesh, That's very odd. What status are you trying to set? Let me see if I can achieve the same result...
[14:44] <mdeslaur> deryck: ok, I'll try that, thanks
[14:45] <mistrynitesh> gmb: bug 545843 trying to change the status to 'incomplete'
[14:45] <ubot5> Launchpad bug 545843 in update-manager (Ubuntu) "distribution upgrade fails (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/545843
[14:45] <deryck> mdeslaur, np
[14:45] <charlie-tca> gmb: I have the timeout errors also, trying to set to invalid
[14:45] <charlie-tca> also getting a timeout just adding a comment
[14:45] <deryck> I think the query was only just now killed.  right gmb?
[14:46] <gmb> deryck, Yes.
[14:46] <gmb> mistrynitesh, Can you try one more time for me?
[14:47] <mistrynitesh> gmb: sure
[14:47] <mistrynitesh> just a moment
[14:48] <mistrynitesh> gmb: success!
[14:49] <gmb> mistrynitesh, Cool.
[15:31] <leonardr> doctormo, who can i talk to about upgrading the version of launchpadlib packaged with lucid? i don't think it's you, but i know you know who it is
[15:53] <james_w> leonardr: any Ubuntu developer can help you
[15:53] <james_w> leonardr: Luca and I have dealt with it the most
[15:54] <leonardr> james_w: this is re: bug 581652, which you've commented on. i'm fine with putting a post-0.9.14 version of lazr.restfulclient into lucid. that will solve the problem for pretty much everyone
[15:54] <ubot5> Launchpad bug 581652 in lazr.restfulclient "Handle HTTP 304's correctly (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/581652
[15:55] <leonardr> if you can do it, that'd be great. if you need me to answer any questions i'm happy to help
[15:56] <james_w> leonardr: just sticking a new version of lazr.restfulclient in to lucid isn't necessarily easy, or the right thing to do
[15:56] <james_w> leonardr: we are free to fix bugs in lucid though
[15:56] <james_w> and any older releases
[15:57] <leonardr> james_w: that's what i was afraid of. that's why i didn't originally say in 581652 "just upgrade the lucid version"
[15:57] <leonardr> 0.9.14 has two changes. the first is to make lazr.restfulclient capable of handling certain documents if launchpad serves them
[15:57] <leonardr> the second is to change the User-Agent so that launchpad knows to serve those documents
[15:58] <leonardr> to fix this bug we would have to port both changes. it's complicated by the fact that if you just use the version in lucid forever, you will never have this problem
[15:58] <james_w> leonardr: two changes with respect to what?
[15:58] <leonardr> with respect to lazr.restfulclient 0.9.13
[15:58] <james_w> leonardr: but that's not the version in lucid
[15:58] <james_w> 0.9.11
[15:59] <leonardr> i'll check, but the stuff in 0.9.12 and 0.9.13 is probably not essential
=== deryck is now known as deryck[lunch]
[15:59] <james_w> and I don't believe we have to apply both those changes
[16:00] <james_w> can't we just stop it choking on the 304s that httplib2 will give it once a Cache-Control header is in the cache?
[16:00] <leonardr> you're right, maybe we can just make lazr.restfulclient handle those documents. but that would be very difficult to test if the documents must pre-exist in the cache
[16:03] <leonardr> james_w: you might be able to backport just this revision: http://paste.ubuntu.com/436801/
[16:03] <leonardr> (r94 of lazr.restfulclient)
[16:03] <leonardr> and there are tests for it, so my earlier worry was unfounded
[16:05] <james_w> yes, that would probably be enough
[16:27] <doctormo> leonardr: I theni that's the MOTU who pushes it to debian
[16:27] <doctormo> But I
[16:27] <doctormo> m not tottally confident on the packaging side of things
[16:27] <leonardr> doctormo: i think james_w is handling it?
[16:28] <shtylman> the vcs import tool cannot handle: git://gitorious.org/+qtwebkit-developers/webkit/qtwebkit.git
[16:29] <shtylman> it fails to import that git repo
[16:29] <james_w> leonardr: I'm not working on it currently
[16:29] <leonardr> james_w: sure, but is it something you're comfortable dealing with eventually?
[16:29] <leonardr> or should i find someone else?
[16:30] <jelmer> shtylman: what's the error it gives?
[16:32] <shtylman> jelmer: http://paste.ubuntu.com/436813/
=== noodles775 changed the topic of #launchpad to: http://launchpad.net/ | Read https://help.launchpad.net/ for help | Help contact:  | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[16:33] <shtylman> jelmer: fyi https://code.launchpad.net/~kubuntu-members/qtwebkit/trunk
[16:34] <james_w> leonardr: I could do it, but I don't know when I would get to it.
[16:35] <jelmer> shtylman: It's a known issue for which a fix is available; the fix will hopefully land in lp:launchpad this week.
[16:35] <jelmer> shtylman: If you can't wait that long you should be able to create a manual import using bzr-git (which is also what launchpad uses)
[16:36] <leonardr> james_w: no problem, i'll just assign bug 581652 to you and leave a comment outlining the situation. i'm in no hurry--the bug doesn't affect me
[16:36] <ubot5> Launchpad bug 581652 in lazr.restfulclient "Handle HTTP 304's correctly (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/581652
[16:36] <shtylman> jelmer: I can wait... thanks :)
=== deryck[lunch] is now known as deryck
=== Chex_ is now known as Chex
=== salgado is now known as salgado-lunch
[17:14] <jcastro> deryck: I added what I think are actions from the notes to this spec: https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-bugs
[17:14] <jcastro> deryck: please feel free to mangle accordingly
=== yofel_ is now known as yofel
=== beuno is now known as beuno-lunch
[17:52] <GarrettS-MSFT> Is there a launchpad admin, or someone who knows one hell of a lot about LP that could assist me in getting a grip on the best way to work with LP, multiple projects, multiple developers, etc?  The user guide is great, but our project is about to start getting complicated and I'd like to shortcut the learning curve.
[17:54] <bitmonk1> GarrettS-MSFT: it's pretty straightforward.  what's about to get complicated that you don't know how to solve?
[17:56] <GarrettS-MSFT> I've asked for a project group to be created, as we're starting to develop multiple projects that should be handled seperately. I'm wondering if each project should have a team, or is one team for all projects correct.
[17:56] <bitmonk1> i think whatever works for your needs is 'correct'.
[17:56] <GarrettS-MSFT> and should the trunk branch owner be the team
[17:57] <GarrettS-MSFT> LOL
[17:57] <bitmonk1> i'm absolutely serious, if there was only one way to do it, you wouldn't be granted an option.
[17:57] <GarrettS-MSFT> We're all pretty damn new to LP, and since we're starting all of the code from scratch, we've got little experience with making the choices.
[17:58] <bitmonk1> the trunk branch owner should probably be a team, but it might not be the overarching team, you could have a 'review' team which merges branches into trunk, for instance ..
=== matsubara is now known as matsubara-lunch
[18:02] <GarrettS-MSFT> So if we have multiple teams working on multiple projects, we should create small 'LP teams' for each one, which own the branch?
[18:04] <bitmonk1> that can certainly have value.  i'd browse around some of the big projects on LP as examples .. FireFox, for instance, is fully managed by the Mozilla Team, there is no sub-team, but I know there are some projects with more finely grained controls ..
[18:04] <bitmonk1> it may facilitate collaboration to have less complicated access control.. and you can change it whenever you want..
[18:04] <bitmonk1> nothing is really written in stone except the project name afaict.
[18:05] <GarrettS-MSFT> LOL... which is funny, because I only figured out that we wanted a project group this week.
[18:07] <GarrettS-MSFT> and it should have been called CoApp instead of our first project (which should have been coapp-engine or something)
=== salgado-lunch is now known as salgado
=== oubiwann_ is now known as oubiwann
=== beuno-lunch is now known as beuno
[18:47] <chx> It seems I can't contact to launchpad with bzr :(
[18:47] <chx> Lately LP seems to be a bit wonky?
[18:54] <flan> One of the projects I work on encountered some intermittent problems with pushing last night.
[18:54] <flan> (I don't know if they're ongoing or not)
[18:54] <flan> America-timey last-night.
[18:54] <chx> yeah it's back
=== matsubara-lunch is now known as matsubara
=== GarrettS-MSFT is now known as GarrettS-Busy
=== EdwinGrubbs is now known as Edwin-lunch
[20:06] <deryck> jcastro, sorry I never responded.  I'll long now at the spec.
[20:06] <deryck> I like the liberal use of the word "Investigate" ;)
[20:07] <jcastro> :)
[20:07] <deryck> I think it works as is.  We can chat later about investigation findings and updating then.  cool?
[20:09] <yofel> does anyone here have an idea why soyuz would build an ANY package on i386 only? https://edge.launchpad.net/ubuntu/+source/python-kinterbasdb/3.3.0-2
[20:12] <jcastro> deryck: yeah, sounds good, jono asked me to clear up "investigate" so I'll flesh that out a bit and then you can just fix it up how you'd like
[20:12] <deryck> jcastro, yeah, I think a couple of them we could just commit to.
[20:13] <deryck> jcastro, and others are a bit ambitious, so maybe having a design doc on the feature would be a worthwile outcome.
[20:13] <jcastro> deryck: yeah
[20:13] <jcastro> oh I am totally prepared for POSTPONED for a bunch of them
[20:13] <jcastro> but I might as well ask, heh
[20:14] <deryck> heh, fair enough.
[20:14] <deryck> But if it's worth doing, something along the path to done would be useful.
[20:16]  * deryck is out for the day
=== Edwin-lunch is now known as EdwinGrubbs
=== apachelogger_ is now known as darthvader
=== darthvader is now known as apachelogger
=== matsubara is now known as matsubara-afk
=== GarrettS-Busy is now known as GarrettS-MSFT
=== mok0_ is now known as mok0
=== jamalta_ is now known as jamalta
=== salgado is now known as salgado-afk
=== Philip6 is now known as Philip5