[01:41] <poolie> are people getting "loading results failed" in person or product searches?
[01:41] <poolie> i seem to
[01:42] <mwhudson> person search is failing all the time
[01:42] <poolie> right
[01:42] <mwhudson> wasn't aware project search was, but someone else might be :-)
[01:42] <poolie> i guess i meant, should i file a bug?
[01:42] <mwhudson> poolie: it's pg8.4 fallout, basically
[01:45] <poolie> bug 655802
[01:45] <poolie> ok
[01:45] <lifeless> check the timeouts page first ;)
[01:45] <lifeless> but I don't mind dups
[01:45] <lifeless> if you looked and couldn't see a match
[01:45] <lifeless> yes, thats the one
[01:45] <poolie> sigh
[01:46] <poolie> ah well, one step backwards, several steps forwards
[01:46] <lifeless> the problem is that its timing out spectacularly
[01:47] <lifeless> not slightly
[02:16] <micahg> lifeless: will no edge deployments mean edge will be behind or just the same as the regular LP?
[02:19] <lifeless> it means regular LP will be moving forward, hopefully at the same rate edge did
[02:19] <lifeless> or possibly faster
[02:20] <micahg> lifeless: ok, but I won't be behind by staying on edge, right?
[02:21] <lifeless> micahg: we're going to be deleting edge
[02:21] <lifeless> micahg: you won't be *behind*, but I wouldn't stay on edge
[02:22] <wgrant> The redirect will stop, right?
[02:22] <micahg> lifeless: ok, wasn't there something about the beta testers group still testing new features though?
[02:24] <lifeless> micahg: yes
[02:24] <lifeless> that will happen on the prod domain
[02:24] <lifeless> we have a new mechanism for exposing features that aren't 'done'
[07:57] <sydbarrett74> how well does launchpad's issue tracker work with a project hosted at bitbucket?
[09:27] <geser> bigjools: any idea what happened to https://edge.launchpad.net/ubuntu/+source/pciutils/1:3.1.7-4ubuntu3/+build/2011386? it just says "Failed to build", no build log, no date, no builder
[09:28] <bigjools> geser: we had some failed-to-upload builds that stuck in the "uploading" state because of a bug.  We fixed those builds' data but the log is lost unfortunately.
[09:30] <geser> so just ask for a give-back to get fresh logs?
[09:30] <bigjools> geser: yes
[09:31] <geser> look all affected builds like this one?
[09:31] <bigjools> yep
[09:31] <geser> ok, thanks
[09:33] <AnAnt> Hello, how can I create a branch of a bzr repository that is on launchpad ? without having to download then re-upload again to LP ?
[09:56] <popey> Greetings all!
[09:59] <popey> I have a problem. I uploaded tomboy 1.5.1-0ubuntu1~ppa~maverick0 to ppa:tomboy-packagers/development (which can be seen at https://edge.launchpad.net/~tomboy-packagers/+archive/development
[09:59] <popey> I then tried to upload tomboy  1.4.0-0ubuntu4~ppa~maverick0 to ppa:tomboy-packagers/stable  <- different ppa
[10:00] <popey> I got a rejection from launchpad "tomboy_1.4.0-0ubuntu4~ppa~maverick0.dsc: Version older than that in the archive. 1.4.0-0ubuntu4~ppa~maverick0 <= 1.5.1-0ubuntu1~ppa~maverick0"
[10:00] <popey> why does lp care that the version is older, its a different ppa
[10:00] <bigjools> popey: there must be an older version in that one
[10:00] <popey> que?
[10:01] <bigjools> one sec
[10:02] <bigjools> popey: hmm that's indeed odd
[10:04] <popey> possibly a bug?
[10:04] <bigjools> quite possibly
[10:04] <wgrant> I've not seen that before.
[10:04] <wgrant> Sure you uploaded to the right PPA?
[10:04] <bigjools> but very odd since you'd think a few more people would complain
[10:04] <popey> Good signature on /home/alan/Development/tomboy/maverick/ppa/tomboy_1.4.0-0ubuntu4~ppa~maverick0.dsc.
[10:04] <popey> er, oops
[10:04] <popey> alan@hactar:~/Development/tomboy/maverick/ppa$ dput ppa:tomboy-packagers/stable tomboy_1.4.0-0ubuntu4~ppa~maverick0_source.changes
[10:04] <popey> looks like it
[10:04]  * bigjools looks in the log file
[10:05] <popey> however, I do have a personal ppa and I have seen in the past that dput has uploaded to my personal one (where 1.5 does indeed reside) rather than the one I specified
[10:05] <popey> now if it did go to my personal ppa ~popey then I can understand the rejection completely
[10:05] <bigjools> Considering changefile ~popey/ppa/ubuntu/tomboy_1.4.
[10:05] <bigjools> 0-0ubuntu4~ppa~maverick0_source.changes
[10:05] <bigjools> yes, it did :)
[10:05] <popey> ok, so why?
[10:06] <wgrant> I think your dput.cf is non-default.
[10:06] <popey> yes, thats possible
[10:06] <popey> http://paste.ubuntu.com/517302/
[10:06] <StevenK> Perhaps your [ppa] section doesn't contain %s
[10:06] <wgrant> StevenK: Do you have a ~/.dput.cf?
[10:06] <wgrant> Er, popey ^^
[10:07] <popey> http://paste.ubuntu.com/517304/  is my dput.cf
[10:07] <popey> have I made a booboo?
[10:07] <wgrant> Well, there's the problem.
[10:07] <StevenK> That's exactly it
[10:07] <StevenK> incoming = ~popey/ppa/ubuntu/
[10:07] <wgrant> The [ppa] section there overrides the one in /etc/dput.cf
[10:07] <popey> sorry, thats my ~/.dput.cd
[10:07] <popey> *cf
[10:07] <StevenK> It will ignore what you say after the : since the incoming is always your personal ppa
[10:08] <wgrant> popey: There's a [ppa] section /etc/dput.cf which does what you want. You have a custom one in ~/.dput.cf which doesn't.
[10:09] <StevenK> popey: Besides, the subject of the mail would have told you which PPA is making the rejection
[10:09] <popey> so just remove the [ppa] stanza in my ~/.dput.cf ?
[10:09] <wgrant> Yup.
[10:09] <wgrant> And all the others, unless you really want that slightly shorter name.
[10:09] <popey> heh
[10:09] <popey> yeah, that was made before I realised you could just explicitly specify the ppa on the command line
[10:09] <popey> StevenK: nope, the mail does not
[10:10] <wgrant> StevenK: The acceptance email does. The rejection one does not.
[10:10] <StevenK> popey: Really? What's the subject?
[10:10] <StevenK> Oh, sigh
[10:10] <StevenK> BUG
[10:10] <popey> http://paste.ubuntu.com/517306/ is the mail
[10:10] <wgrant> It's still "blah.changes rejected"
[10:10] <bigjools> yay
[10:10] <wgrant> But:
[10:10] <wgrant> X-Launchpad-PPA: popey
[10:10] <StevenK> X-Launchpad-PPA: popey
[10:10] <popey> lol
[10:10] <StevenK> So there
[10:10] <popey> really?
[10:10] <StevenK> The mail *does* say
[10:11] <wgrant> StevenK: ... just not in any useful location.
[10:11] <popey> yes, everyone reads their mail headers :)
[10:11] <bigjools> in a nonobvious way
[10:11] <popey> that is quite funny :)
[10:11] <popey> well, thanks for your time everyone, sorry to have bothered you with a bit of a silly question :)
[10:11] <wgrant> popey: That may deserve a dput bug to fail when attempting to substitute a path into something that doesn't take a substitution.
[10:12] <StevenK> And it certainly is a Launchpad bug that the Subject doesn't beat you with the PPA name
[10:13] <popey> ok, will file both bugs
[10:13] <StevenK> I'm creating a branch for the lp bug now
[10:13] <popey> *hugs*
[10:14] <wgrant> I guess nobody should care if we change the rejection email format.
[10:14] <StevenK> Oh, I didn't say it would fix it, just that I'm making a branch ;-)
[10:14] <wgrant> Unlike the debate over the acceptance one.
[10:14] <StevenK> wgrant: I was only going to twiddle the subject for PPAs
[10:15] <wgrant> I've gone to fix it a couple of times, but then decided that I wouldn't until I had time to fix them all.
[10:17] <popey> ok, this is odd, my latest mail _does_ have it in the subject!
[10:17] <popey> so does that mean it doesn't show the ppa name if its your own default ppa?
[10:18] <popey> but does for any other ppa?
[10:18] <StevenK> Could be
[10:18] <popey> oh, this was accepted mail
[10:18] <popey> rather than rejected
[10:18] <popey> well that's inconsistent
[10:18] <StevenK> popey: Please learn to read
[10:18] <StevenK> :-)
[10:18] <popey> heh, well, the subject went off the end of the browser
[10:19] <StevenK> And who's fault is that for using gmail? :-)
[10:19] <bigjools> back off StevenK, he's likely to be at UDS and he's bigger than you
[10:19] <StevenK> Awww, popey is just a big teddy bear
[10:19] <popey> you're lucky, I'm not at UDS :)
[10:19] <StevenK> popey: You usually are, that's a pity
[10:20] <popey> yeah, hey ho
[10:20] <popey> I'm sure lots of more important and clever contributors will be there instead :D
[10:20] <popey> (that was meant in a nice way in case it's interpreted otherwise)
[10:24] <popey> bug 664380 filed
[10:29] <popey> bug 664382 filed for dput
[10:43] <noodles775> Does someone know what setting causes a team to be subscribed to a branch that I push? I've got two projects with private branches, both have the same team as the maintainer/driver as well as owner of trunk.
[10:44] <noodles775> Yet only one of those results in branches with the team automatically subscribed?
[10:44]  * noodles775 starts looking through the source.
[10:44] <wgrant> Sounds like the projects have different branch visibility policies.
[10:46] <noodles775> Hrm, when looking at the code overview of both projects, both say: "New branches you create for project name are private initially."
[11:04] <jussi> hi all
[11:05] <jussi> how do I report a spammer on LP?
[11:05] <jussi> ie. bug 64848 last comment
[11:05] <jussi> https://bugs.edge.launchpad.net/ubuntu/+source/k3d/+bug/64848
[11:10] <Tak> hmm - is there a way to simultaneously register a branch and pull to it from an existing branch on lp? (àla github's "Fork") ?
[11:11] <wgrant> Tak: You don't need such a thing with Bazaar, since it will only upload the data specific to your branch.
[11:12] <wgrant> So just branch locally and push your changes.
[11:13] <wgrant> (Launchpad tells bzr to automatically stack your branch on top of the project's development focus branch, which allows it to share the revision data)
[11:15] <Tak> so for a feature branch of bzr, I need to: a) Register a branch on bzr  b) Manually branch lp:bzr  c) Push that to my feature branch  ?
[11:16] <Tak> (bzr picked as a random example)
[11:16] <spiv> Tak: just b and c, you can skip a.
[11:17] <Tak> but if I skip a, do I still get the auto-stacking?
[11:17] <spiv> Yes.
[11:17] <wgrant> You never need to do a). It will automatically create a new branch if you push to a non-existent location.
[11:17] <Tak> ...and there's no way I can accomplish b+c from the web interface?
[11:17] <Tak> ...so what's the point of a?
[11:18] <wgrant> a) is mainly used to register mirrored branch.
[11:18] <spiv> Tak: no, but there's really benefit to doing b+c without having a local branch.
[11:18] <wgrant> There's been an argument to remove explicit registration of non-mirrored branches.
[11:18] <wgrant> Tak: Why would you want to do b+c without making changes locally?
[11:18] <Tak> As a preemptive setup step to making changes locally
[11:18] <spiv> Er, "really *no* benefit" is what I meant to say!
[11:18] <Tak> just a different workflow
[11:19] <wgrant> bzr branch lp:bzr; hack hack hack; bzr push lp:~wgrant/bzr/some-feature
[11:19] <wgrant> vs. click click click; bzr branch lp:~wgrant/bzr/some-feature; hack hack hack; bzr push lp:~wgrant/bzr/some-feature
[11:19] <Tak> precisely
[11:19] <Tak> Some people will prefer to begin with click click click ;-)
[11:20]  * wgrant is very confused.
[11:20] <spiv> Tak: then they can use groundcontrol :)
[11:20] <Tak> particularly those coming from those other dirty vcss
[11:20] <spiv> Or whatever their bzr GUI of choice is.
[11:21] <spiv> (But that GUI would just provide a click click click way to do "bzr branch lp:bzr; hack hack hack; bzr push lp:...")
[11:28] <Tak> I think another perceived benefit of that workflow will be that the push branch is the default remote branch from the beginning: click click click, paste url into bzr explorer, hack hack hack, click push, not have to choose between two branches (even though the choice is obvious) or look up the push url now
[11:29] <Tak> but ok
[11:30] <Tak> the wiki that's being used for launchpad help/dev ... is that part of launchpad, or some external thing?
[11:30] <wgrant> It's a separate installation of moinmoin.
[11:31] <Tak> ah ok
[11:37] <spiv> bzr automatically remembers the first push location (and where you first branched from), though.
[11:37] <wgrant> And it can be configured to automatically guess push locations based on the branch name.
[11:37] <spiv> So at least from the command line you don't need to choose between them, you just do "bzr merge" or "bzr push" or whatever it DTRT.
[11:37] <wgrant> So it turns into 'bzr branch trunk some-feature; hack hack hack; bzr push'
[11:38] <spiv> Perhaps we just need a web page that says "trust us, we have trimmed it down to something more minimal and easy than a web form can give you" ;)
[11:51]  * maxb glares at the PPA publisher
[11:52] <maxb> "same version has unpublished binaries in the destination archive for Lucid, please wait for them to be published before copying" - ooi, why that restriction?
[11:54] <Tak> that web page would actually help :-)
[11:54] <wgrant> maxb: The check is a bit over-broad.
[11:55] <wgrant> maxb: It means to check that there are no pending binary *uploads*. But it also catches pending binary publications, which are fine.
[11:55] <maxb> ah, I see
[11:56] <wgrant> (binary uploads don't have publications created until process-accepted.py runs, which happens just before the publisher. copying before then will miss the binaries.)
[12:14] <Tak> aww - is there a project for fogbugz tracker support?
[14:06] <bigon> mmm I just try to delete a bug watch on a bug and I got OOPS-1755EC886
[14:06] <bigon> https://bugs.edge.launchpad.net/ubuntu/+source/libssh/+bug/663823 << that bug
[14:10] <achiang> hello, i'm creating a new PPA and it's asking me about Displayname: I've been staring at the description for this field and still have no clue what it really means...
[14:11] <achiang> do i want displayname to match my project's name? or should it match my launchpad name? the text about the "signing key's description" is confusing
[14:16] <noodles775> achiang: you can always change the display name. Just enter the name of your project for now and when you save, you'll see how it is used on the page (it's the main heading of the PPA page).
[14:17] <wgrant> achiang: The text about the signing key description is no longer correct. You can ignore it.
[14:17] <wgrant> So you can rename it as you see fit.
[14:17] <achiang> noodles775: thank you
[14:17] <bigjools> p-d-r is very busy :)
[14:17] <achiang> wgrant: is there a bug about the obsolete text?
[14:17] <achiang> wgrant: or should i file one?
[14:18] <wgrant> achiang: Please file a new one at https://bugs.launchpad.net/soyuz/+filebug.
[14:18] <achiang> wgrant: wilco, thx
[14:36] <ogra_ac> bigjools, around ? i have a prob with PPA privacy
[14:38] <ogra_ac> well, or any LOSA ^^^^
[15:14] <ogra_ac> hello ? any LOSA here ?
[15:16] <Chex> ogra_ac: hi there, sorry for the delay. what privacy issue?
[15:16] <jcastro> deryck: are you guys planning a daily builds session for UDS?
[15:16] <jcastro> deryck: outside the "normal" launchpad upstream one I mean
[15:16] <ogra_ac> Chex, https://edge.launchpad.net/~tiomap-dev there is a privare ppa
[15:17] <deryck> hi jcastro.  I don't know on that one.  Maybe jml or bigjools would know.
[15:17] <ogra_ac> Chex, well, there was, someone uploaded to private-stable to then notice it wasnt actually private ... i deleted it for now, we would need to recreate it and actually make it private
[15:18] <jcastro> deryck: oh right, you're bugs, sorry. :)
[15:18] <ogra_ac> Chex, i somehow couldnt find any UI option for creating a private PPA so i suspect a LOSA is required
[15:18] <deryck> jcastro, no worries :-)
[15:19] <Chex> ogra_ac: yes, create a blank PPA, and then send a request in to have the PPA converted to a private PPA on canonical-answers, or you can request it here
[15:20] <ogra_ac> Chex, are you able to fully delete the remainings of https://edge.launchpad.net/~tiomap-dev/+archive/private-stable ?
[15:20] <ogra_ac> Chex, or re-enable it
[15:20] <ogra_ac> so we can make it private
[15:20] <Chex> ogra_ac: let me look
[15:20] <micahg> can someone shuffle the PPA builders to clear the amd64 queue?
[15:22] <bigjools> micahg: yes, doing so now
[15:22] <Chex> ogra_ac: " This archive already has published sources. It is not possible to switch the privacy. "
[15:22] <Chex> ogra_ac: hmmmm
[15:22] <micahg> bigjools: thanks
[15:22] <ogra_ac> Chex, weird, afaik the upload was rejected
[15:22] <ogra_ac> so there should nothing be published
[15:23] <bigjools> ogra_ac: there is a deleted source in it
[15:23] <bigjools> published on the 18th
[15:23] <ogra_ac> ah
[15:24] <ogra_ac> grmpf
[15:27] <ogra_ac> can yu delete it somehow ?
[15:28] <Chex> ogra_ac: I will try
[15:28] <ogra_ac> thanks
[15:30] <bigjools> there's no way of deleting PPA history
[15:30] <bigjools> you need a new PPA
[15:31] <ogra_ac> can we rename the deleted one ?
[15:31] <ogra_ac> TI would like to keep the name
[15:32] <bigjools> no
[15:32] <bigjools> you need a new PPA
[15:32] <ogra_ac> hmm, k
[15:32] <bigjools> ogra_ac: stable-private? :)
[15:33] <ogra_ac> let me discuss with TI first ;)
[15:57] <Chex> bigjools: thanks for the help
[16:05] <bigjools> Chex: np
[16:06] <ogra_ac> yeah, thanks a lot
[16:06] <ogra_ac> TI has to discuss first, not sure they'll come back to me today already
[16:24] <micahg> is there a URL to the preferred series to translate in LP for an Ubuntu source package?
[16:25] <danilos> micahg, no, but there's a bug about making pages like http://translations.launchpad.net/ubuntu/+source/nautilus be that
[16:26] <micahg> danilos: heh, ok, thanks, do you have the # so I can subscribe
[16:26] <danilos> micahg, https://bugs.edge.launchpad.net/rosetta/+bug/127884 (was looking for it :); it's pretty old and not very high on our priority list, so we'd be happy if someone steps along and helps with getting it fixed :)
[16:28] <micahg> danilos: it would just make the ubufox code a little cleaner...I'm not interested enough ATM to make it happen, but thanks
[16:28] <danilos> micahg, yw, hopefully we'll get around to it soon enough
[16:43] <exarkun> So, how should I feel about this, exactly?
[16:43] <exarkun> exarkun@top:~/Projects/game/branches/framedrops$ bzr push
[16:43] <exarkun> Using saved push location: lp:~game-hackers/game/framedrops
[16:43] <exarkun> This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~game-hackers/game/framedrops/. See 'bzr help working-trees' for more information.
[16:43] <exarkun> Created new branch.
[17:25] <doctormo> I seem to ave a problem with launchpad api, the getBranchByURI isn't working any more, causing ground control failures.
[17:26] <doctormo> I tried to see if it was the new trunk branch form causing the issue, but both new and old forms failed.
[17:37] <shadeslayer> doctormo: btw i think your blogged is either a) banned in india or b) the site was experiencing some issues when i accessed it
[17:37] <doctormo> shadeslayer: It's banned in India, known problem.
[17:38] <shadeslayer> man.. :(
[17:38] <shadeslayer> doctormo: why?
[17:38] <doctormo> Unknown
[17:38] <doctormo> Maybe the government didn't like a socialist blogger?
[17:38] <shadeslayer> weird officials here -.-
[17:39] <shadeslayer> hehe :P
[18:13] <ricotz> hello, could someone please kill this build - https://edge.launchpad.net/~ricotz/+archive/staging/+build/2005064
[18:23] <doctormo> No one online for answering my launchpad api query?
[18:25] <james_w> doctormo, "isn't working any more" may be a bit vague for people to help you
[18:26] <doctormo> james_w: fair enough, returns null when given a valid bzr banch uri.
[18:27] <james_w> doctormo, what url are you giving it?
[18:28] <doctormo> james_w: the urls stored in the .bzr/branch/branch.conf
[18:28] <james_w> doctormo, can you give precisely one that is failing?
[18:28] <james_w> the urls that are stored have changed with different bzr versions I think, perhaps that is it
[18:28] <doctormo> bzr+ssh://bazaar.launchpad.net/%2Bbranch/erato/
[18:29] <james_w> there, bzr is now storing that rather than the expanded form
[18:29] <james_w> I bet that either getByURL doesn't know about +branch
[18:29] <doctormo> I tried the expanded form too.
[18:29] <james_w> or it is a URL escaping issue
[18:30] <doctormo> bzr+ssh://bazaar.launchpad.net/~doctormo/erato/trunk/
[18:33] <james_w> doctormo, does http://bazaar.launchpad.net/~doctormo/erato/trunk/ work? Does lp:~doctormo/erato/trunk/?
[18:35] <doctormo> james_w: http://bazaar.launchpad.net/~doctormo/erato/trunk/ works
[18:36] <doctormo> lp:~doctormo/erato/trunk/ doesn't work
[18:38] <james_w> interesting
[18:38] <doctormo> http://bazaar.launchpad.net/%2Bbranch/erato/
[18:38] <doctormo> doesn't work
[18:42] <james_w> doctormo, all of http sftp bzr+ssh and lp work for me with the ~doctormo url
[18:45] <doctormo> james_w: Ah without the end / it fails.
[18:46] <james_w> doctormo, that shouldn't make a difference, and doesn't fail for me with bzr+ssh
[18:46] <doctormo> james_w: Weird, it fails here. :-/
[18:47] <doctormo> I'm not sure how I'm going to solve this one, I think I might have to hack out the bzr branch location and replace it with the non expanded form.
[18:49] <james_w> doctormo, bug 664637
[18:49] <doctormo> thanks :-)
[18:50] <smoser> hey all. i'm new to launchpadlib and launchpad api.  i'm trying to get to builds of a given package in a given distribution.
[18:50] <smoser> i find the 'ubuntu' distribution in lp.distributions.entries. and find its archives_collection_link
[18:50] <smoser> (https://api.launchpad.net/1.0/ubuntu/archives)
[18:51] <smoser> but i dont see anything in launchpad lib for dealing with that
[18:51] <james_w> smoser, you are getting tricked by the obtuse documentation
[18:52] <smoser> i assumed that if i did get a handle to such a thing i could use getBuildRecords
[18:52] <james_w> smoser, for archive in lp.distributions['ubuntu'].archives:
[18:52] <smoser> james_w, well that or my own stupidity . always get in the way.
[18:52] <james_w> smoser, it's raw API documentation, and launchpadlib provides a layer of sugar on top
[18:53] <james_w> basically foo_link becomes a foo attribute that is an object that is whatever is at the URI that the _link points to
[18:53] <smoser> right.
[18:53] <smoser> i just didnt' see the distributions objects.
[18:53] <james_w> similarly bar_collection_link becomes a bar attribute that is the collection at that URI
[18:53] <smoser> only the 'entries'
[18:54] <james_w> right, also the top level has some special collections defined for getting at things easily
[18:54] <james_w> lp.bugs, lp.projects, lp.distributions, lp.branches etc.
[18:55] <smoser> so lp.distributions['ubuntu'].archives
[18:55] <smoser> i would have thought that to be an archihttps://launchpad.net/+apidoc/1.0.html#archive)ve (
[18:56] <smoser> (paste fail)
[18:56] <smoser> ubar=lp.distributions['ubuntu'].archives
[18:56] <smoser> but i dont see much under dir(ubar)
[18:56] <james_w> it's a collection of archives
[18:56] <smoser> ah.
[18:57] <james_w> use lp.distributions['ubuntu'].main_archive to just get the one you probably care about
[18:57] <james_w> others might be PARTNER etc.
[19:07] <smoser> ok. so i *think* i'm at the end of my line here. lp -> distributions -> archives -> builds[source-package]
[19:07] <smoser> but i was hoping that for a build i could find info like its version and binary packages produced by it
[19:07] <smoser> (and their versions and such)
[19:18] <james_w> smoser, you need build.current_source_publication for the version
[19:18] <james_w> doesn't seem like the resulting binary packages are exposed
[19:19] <james_w> https://edge.launchpad.net/+apidoc/devel.html#source_package_publishing_history is what current_source_publication is
[19:19] <james_w> getPublishedBinaries may be sort of what you want for the binary packages produced by the build
[19:19] <smoser> fudge
[19:20] <smoser> so, for anything not currently in the archive, current_source_publication is empty
[19:25] <smoser> i was hoping that i could get historic data
[19:26] <lifeless> what sort of historical data?
[19:26] <smoser> well, specifically i was hoping to abuse this
[19:26] <smoser> and crawl builds
[19:27] <lifeless> I know the words, I don't know the meaning in this context ;)
[19:27] <smoser> so that i could map package binary version -> source version for a package-binary-version not currently in the archive.
[19:28] <smoser> basically, i have a "manifest" of a UEC image build.  the manifest is  a list of 'binary-package version'
[19:28] <smoser> i want to compare to manifests, and get changelogs for the changes.
[19:29] <smoser> that requires that i be able to determine the source package version of a binary package which  may not be in the archive at the moment.
[19:29] <smoser> (because it could be replace by a newer one in -updates or -security)
[19:31] <smoser> basically, the only way i can see to map binary-package-version -> source-package-version depends on binary-package-version being in the archive "right now"
[19:31] <lifeless> hmmm
[19:32] <smoser> (the real trick here is that binary-version is not always source-version)
[19:33] <smoser> the trick i'm willing to ignore for the moment is that a binary package may have moved source packages.
[19:34] <smoser> the first is biting me now, the second will bite future-smoser
[19:37] <smoser> lifeless, here is where you say "Oh, i know how to do that ... "
[19:38] <lifeless> I'm reasonably sure we store that historical data
[19:38] <lifeless> I'm not sure its exposed on the API
[19:39] <smoser> so should i open a bug ?
[19:42] <smoser> it doesn't even look to me that the binary package knows what source it came from
[19:42] <smoser> https://edge.launchpad.net/+apidoc/devel.html#binary_package_publishing_history
[19:43] <lifeless> I think it knows what build it came from and that knows what sourcepackage was used
[19:43] <lifeless> IMBW
[19:43] <lifeless> I'd start with a Question I think
[19:44] <smoser> i dont see binary_package -> build at all
[19:50] <james_w> binary packages aren't exposed at all
[19:50] <james_w> publishings of binary packages are, along with some attributes that look up e.g. name and version on the binary package
[19:50] <james_w> but the binary package -> build isn't exposed from what I can see
[20:39] <smoser> well, lifeless, james_w https://answers.launchpad.net/launchpadlib/+question/130600
[20:39] <smoser> hopefully that gives an exapmle of what i want and why i'm doing this.
[21:26] <achiang> how does launchpad buildd treat debian's "unstable" distro when used in a changelog?
[21:27] <achiang> e.g., a version string that looks like: libfoo (1.2.0-3) unstable; urgency=low
[22:05] <wgrant> achiang: The buildd doesn't care. But the Launchpad won't accept the upload if you try to upload it to unstable.
[23:10] <achiang> wgrant: thanks, makes sense.