[00:39] <duffyd> jamesh: ping
[00:39] <jamesh> duffyd: hi
[00:44] <duffyd> jamesh: hi did you get my email?
[00:46] <jamesh> duffyd: just looking at it now.
[00:46] <duffyd> jamesh: sweet
[00:47] <jamesh> so, is there any difference to the set of private keys available locally and on your production system?
[00:48] <jamesh> and do the gpg.conf files differ?
[00:48] <duffyd> both of those tests are run on the same system
[00:49] <duffyd> and same data
[00:49] <jamesh> but with one of them it looks like you're failing to decrypt
[00:50] <duffyd> yeah, that's what's confusing
[00:50] <duffyd> I copied exactly the same data into the test suite
[00:50] <jamesh> are you installing the private keys as part of your test suite?
[00:50] <duffyd> I am if they aren't there
[00:50] <duffyd> but the same code is being run in both cases
[00:51] <duffyd> I've deleted the keys and rerun it too with no joy
[00:51] <jamesh> do you have GPG_AGENT_INFO set in one case but not the other?
[00:51] <duffyd> not that I know of - what's that?
[00:52] <jamesh> gpg-agent is a daemon used to unlock private keys
[00:52] <jamesh> so you don't need to enter your passphrase over and over
[00:53] <jamesh> the gpgme library automatically passes --use-agent to gpg if that environment variable is set
[00:53] <duffyd> oh ic
[00:53] <duffyd> the server and all tests are run with sudo so that would be in the root env?
[00:54] <jamesh> that would lose your env, yes.
[00:54] <duffyd> sorry?
[00:55] <jamesh> sudo will not inherit the environment of the calling process
[00:55] <duffyd> oh ic
[00:56] <duffyd> jamesh: so iow the GPG_AGENT_INFO wouldn't be the cause of the problem?
[01:00] <jamesh> duffyd: I guess it might be worth trying to run "gpg --decrypt" in an environment as close as you can to your testing and production environments and observe any differences.
[01:02] <duffyd> jamesh: so perhaps with 'sudo' then I guess?
[01:02] <jamesh> duffyd: "sudo -s" will give you a shell, which might make it easier to see what is going on
[01:02] <duffyd> ok cool
[01:02] <duffyd> ta!
[01:03] <duffyd> I'm thinking the user it's running under must be the issue
[01:03] <duffyd> I think I may've run the tests under 'root' and the zope server under 'sudo'
[01:03] <duffyd> with my limited indepth knowledge of linux I thought this was the same thing
[01:04] <duffyd> ?
[01:05] <duffyd> jamesh: they are different right?
[01:05] <jamesh> duffyd: depends on what arguments you pass to sudo.
[01:06] <duffyd> just: sudo process
[01:06] <duffyd> we have something called 'supervisor' that runs them up in production
[01:06] <duffyd> and I think it is just started via sudo process too
[01:06] <jamesh> duffyd: without extra arguments, sudo leaves $HOME as is, but will set it to the target user if passed -H
[01:07] <jamesh> and $HOME will affect what configuration gpg will see
[01:07] <duffyd> jamesh: k
[01:07] <duffyd> ahhhh
[01:07] <duffyd> thanks!
[01:07] <jamesh> (assuming you aren't explicitly setting a different config directory)
[01:07] <duffyd> I wouldn't think so
[01:07] <duffyd> I might try that
[01:07] <duffyd> and see if it fixes things
[01:10] <seiflotfy1> hi guys
[01:10] <seiflotfy1> is launchpad freaking out
[01:11] <seiflotfy1> i cant push my latest commits
[01:11] <seiflotfy1> :(
[01:20] <spm> seiflotfy1: wfm, and no server issues I can see. what's the error you're getting?
[01:20] <fuks> maxb: I dont have root on any hosting, so I cant make debian repo
[01:49] <wgrant> fuks: One doesn't need root for that.
[02:00] <fuks> wgrant: how do that?
[02:00] <fuks> how make debian and ubuntu repo on www?
[02:04] <spm> fuks: http://www.google.com.au/search?hl=en&q=howto+make+ubuntu+repo&sourceid=navclient-ff&rlz=1B3GGGL_enAU279AU279&ie=UTF-8
[02:05] <fuks> and everywhere is about install sth
[02:05] <fuks> but i dont have access to install on www
[02:06] <fuks> there is not sth like launchpad for debian ?X_x
[02:06] <fuks> is impossible..
[02:09] <spm> fuks: I'm not sure I follow your problem here? Do you have access to a/any www host to put files on for others to download?
[02:10] <fuks> yes
[02:10] <fuks> but on google is info about install packages for make index etc
[02:10] <fuks> and i cant install any packages
[02:10] <fuks> whatever www server stay on slackware..
[02:11] <spm> so do those steps on a local machine and copy the results up. I'd be highly surprised if any of those indexing tools are host specific.
[02:12] <duffyd> jamesh: running sudo with -H didn't fix the issue :(
[02:12] <duffyd> ugh
[02:50] <squidly> I have a myopenid that I would like to use to be able to login. Is that possible with launchpad?
[02:51] <Ampelbein> squidly: currently not, i think. lp only serves as a openID-provider
[02:52] <Ampelbein> squidly: see https://help.launchpad.net/YourAccount/OpenID?action=show&redirect=OpenID
[02:52] <squidly> Ampelbein: thanks
[02:52] <squidly> looking that over
[02:52] <squidly> any thoughs on letting people login with openid?
[02:52] <Ampelbein> i'm not a canonical/launchpad-official so i can't say anything about that
[02:53] <squidly> okies.
[02:53] <squidly> I use openid on most of my other sites that would be awesome
[03:01] <spiv> squidly: there's a bug open about that, I believe it's being worked on
[03:01] <spiv> squidly: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/210943
[03:03] <calc> any admins around that can check something for me
[03:03] <calc> https://edge.launchpad.net/ubuntu/+upstreamreport <- that says OOo has 36 non-triaged bugs, but it only shows 35 to me
[03:03] <calc> what is the extra bug... a bug itself?
[03:04] <calc> kees with security access couldn't see it either
[03:07] <squidly> spiv: thanks
[03:09] <squidly> they say its on the like for 3.0
[03:24] <spm> calc: '36 non-triaged bugs' - is that the column under the delta symbol between triaged|%|delta|Upstream ?
[03:25] <spm> calc: I ask, as when I click on that particular link off, I see 38 bugs. 3 locked. They apepar to be appport crash reports at title glance.
[03:25] <wgrant> Possibly only the apport bot and reporter can see them.
[03:26] <wgrant> Is thar page's data cached?
[03:26] <spm> the upstreamreport? possibly, but unknown to me. not by squid - per-se tho.
[03:29] <calc> spm: ah ok, yea it shows 36 as the delta to me
[03:29] <calc> spm: but when i click on it only shows me 35
[03:29] <spm> calc: hmm. that would work. I get 38, but 3 are locked - all are appport crashes.
[03:29] <calc> spm: so it seems that if you see 38 then one is probably still missing or it showing one of those 3
[03:29] <spm> no idea why 35 tho.
[03:29] <spm> err 36.
[03:30] <calc> spm: well if you don't see it doesn't exist, right? so nothing for me to worry about, might be a display bug of some sort though
[03:30] <spm> calc: I suspect that the upstream report is cached - as per wgrant's suggestion. is generated maybe a few times a day. 2 of those reports are very recent. 23-3 as in.
[03:30] <calc> spm: are the 3 old bugs or just ones that haven't had a chance to be retraced yet
[03:31] <spm> 1 old, 2 new.
[03:31] <wgrant> spm: That's what I thought.
[03:31] <calc> spm: ah ok i see
[03:31] <wgrant> It looks *very* expensive to calculate.
[03:31]  * spm refrains from asking what on LP isn't expensive to calculate ;-)
[03:31] <wgrant> spm: Are two of those crashes newish?
[03:31] <calc> when i make changes to bugs it seems to update fairly quickly so maybe its a combination of cached data and updated data of some sort
[03:31] <spm> wgrant: yes. 23/3 - UTC as in
[03:32] <wgrant> spm: Oh, I thought you meant reports of runnings of the update script. But I misread.
[03:32] <calc> maybe the old bug then makes it 36
[03:32] <spm>  22 Mar 09 19:30 - hmm maybe not that newish.
[03:32] <wgrant> Hrm.
[03:32] <spm> calc: that would be my assumption, yes.
[03:32]  * wgrant would check the source, but...
[03:33] <spm> hahahaha
[03:33] <wgrant> Only 4 months!
[03:37] <jml> that reminds me
[03:37]  * wgrant wonders what about.
[03:37] <ajmitch> probably 'cleaning' his code
[03:38] <jml> ajmitch: my code is perfect!
[03:38] <ajmitch> and your comments never exhibit any frustration or distaste :)
[03:38] <jml> actually it reminds me about documenting some of the work I've been doing.
[03:40] <jml> ajmitch: I don't know what you're talking about. I'm the very soul of patience.
[03:45] <spm> jml: fair warning. I have copied that line; and will retain it for playback at a time/place of my choosing. :-P
[03:47] <mwhudson> :)
[03:51] <jml> drats. this is going to make it much harder to ask mwhudson about that review :)
[03:53] <mwhudson> it's coming on
[04:01] <jml> ta
[04:02]  * jml gets supplies and starts the first of a series of UI branches.
[04:03] <wgrant> Which UI is being attacked now?
[04:04] <wgrant> Source package branches, or merge proposals?
[04:18] <jml> package branches.
[04:50] <maco> Ampelbein just pointed out that on https://edge.launchpad.net/ubuntu/+source/seahorse-plugins my email address is linking to ~maco-m when if you look at the email address it should be ~maco.m is misparsing punctuation in email addresses a known thing?
[04:51] <wgrant> maco: You have multiple accounts.
[04:51] <wgrant> maco: Merge maco-m into your maco.m.
[04:51] <maco> heh thats what he said
[04:51] <maco> i dont know how i got >1 account though
[04:51] <wgrant> Because you uploaded the package as maco.m@ubuntu.com, and didn't have that address associated with ~maco.m.
[04:52] <wgrant> So it created ~maco-m by mangling the user part of the email address, as it needed a user to link to.
[04:52] <maco> oh
[04:53] <maco> Ampelbein: ok you win
[04:53] <Ampelbein> hah
[05:09] <wgrant> Why does LP not tell me that a scan of a branch is scheduled?
[05:09] <wgrant> It knows, because it is able to tell me there are no revisions once I push, whereas before the push finishes it tells me that it hasn't been pushed to.
[05:10] <wgrant> It will then show the real revisions a couple of minutes later.
[05:12] <mwhudson> wgrant: because we're slack and haven't fixed that bug yet
[05:12] <mwhudson> (it's reported already i think)
[05:12]  * spm has dibs on codebrowse getting fixed first, btw. ;-)
[05:13] <wgrant> Heh.
[05:13] <mwhudson> anyway, most of the proper fix is to remove the delay as much as we can
[05:13] <wgrant> mwhudson: Is the delay because it's slow, or just because it's infrequent?
[05:13] <mwhudson> wgrant: these days, mostly infrequent
[05:13] <wgrant> Good.
[05:13] <mwhudson> i mean, it shouldn't be that long
[05:13] <mwhudson> up to a minute for the puller, then another minute for the scanner to run
[05:14] <spm> really needs some sort of db trigger like device/MQ etc vs cronjobs.
[05:14] <mwhudson> but double handling is stupid and we shouldn't do it
[05:14] <spm> that too
[05:14] <wgrant> Soyuz dispatches builds within seconds.
[05:14] <mwhudson> spm: i don't think we need anything that exciting, really
[05:15] <spm> mwhudson: "everest syndrome" not withstanding?
[05:15] <mwhudson> spm: what's that?
[05:15] <spm> because it's there, and you can.
[05:15] <spm> ie why climb everest. because it's there, and I can
[05:16] <jml> we shouldn't bother with any delay at all for hosting or imported branches though.
[05:17] <jml> but codebrowse & package branches first!
[05:17] <wgrant> Poor codebrowse.
[05:23] <mwhudson> spm: i try not to fall for that one :)
[07:12] <wgrant> noodles775: The false dupe marking was bug #347258.
[07:13] <noodles775> Thanks wgrant... will look into it now...
[08:00] <dominiks> hello, is there any way to turn off locations (on map) on team pages please? it's real pain to wait for 800 flags sometimes :)
[08:05] <wgrant> dominiks: It looks like the next version of Launchpad (to be released in a week) only shows a subset of large teams unless you ask for the whole lot.
[08:06] <dominiks> wgrant: thanks for info.. that'll be fine
[09:48] <wgrant> noodles775: That was a nice quick fix!
[09:49] <noodles775> wgrant: :), yep, but one of many little display issues :/
[09:49] <wgrant> noodles775: JS has that effect on things :(
[09:50] <noodles775> yep.
[10:23] <bigjools> JS is evil
[10:27] <Spads> sudo apt-get install mozilla-noscript
[10:28] <bigjools> it's amazing how many sites completely fail with JS disabled
[10:29] <Spads> I'm more impressed with how many fail gracefully
[10:29] <bigjools> there are some? :)
[10:35] <wgrant> JS makes everything painful :(
[10:35] <bigjools> still, we could be writing Flash
[10:36] <wgrant> bigjools: I somehow suspect that Launchpad's market share would cease to exist.
[10:36] <wgrant> Fairly rapidly.
[10:37] <bigjools> :)
[10:37] <wgrant> At least Flash works fairly similarly throughout the browsers it supports, however.
[10:37] <intellectronica> wgrant: it makes the development process painful, but ideally the end result should be a lot nicer to use. if not then the whole exercise if pointless
[10:37] <wgrant> intellectronica: But it rarely works out well.
[10:37] <bigjools> rarely?
[10:37] <wgrant> Although Launchpad's is a good application - it just needs the bugs ironed out.
[10:38] <tumbleweed> my debian boxs' bzr just upgraded to 1.13 - it now appears to use a https transport by default when talking to launchpad
[10:38] <tumbleweed> can I persuade it not to?
[10:42] <bigjools> what's in your ~/.bazaar/locations.conf ?
[10:42] <bigjools> the public_branch should be bzr+ssh:// ...
[10:44] <tumbleweed> bigjools: lp:
[10:44] <bigjools> tumbleweed: I use bzr+ssh://bazaar.launchpad.net/
[10:45] <tumbleweed> bigjools: ok, yes I can do bzr+ssh
[10:45] <tumbleweed> bigjools: but then I can never use the lp:foo shortcut
[10:46] <bigjools> I use that and it works fine
[10:46] <bigjools> lp: maps to bzr+ssh
[10:46] <tumbleweed> bigjools: I don't think it does any more
[10:47] <tumbleweed> it apporas to be talking to 91.189.90.218:443
[10:47] <tumbleweed> and unfortuantly I'm sitting behind a traffic shaper that doesn't like https very much
[10:47] <bigjools> hmm
[10:47] <bigjools> no idea then, sorry
[10:47] <bigjools> abentley or rockstar can help later when they are around
[10:48] <tumbleweed> in most cases, https is likely to work than ssh
[10:48] <tumbleweed> however this university's IT department sucks
[10:48] <tumbleweed> s/is/is more/
[10:48] <wgrant> That's it talking to the XML-RPC lp: resolver, I suspect.
[10:48] <wgrant> Your traffic shaper is broken.
[10:48] <tumbleweed> wgrant: damn straight
[10:49] <wgrant> (bzr's Launchpad plugin will talk to Launchpad's web servers to work out which URL an lp: URL maps to, and Launchpad redirects HTTP to HTTPS)
[10:50] <tumbleweed> wgrant: ah, so that's what's going on
[10:50] <tumbleweed> thanks
[13:42]  * mpt gets all excited about bug 347756
[13:42] <Ursinha> à/4
[13:42] <Ursinha> err sorry
[13:43] <mpt> and bug 347762
[15:43] <fab2> gmb: are you here?
[19:15] <vadi3> small funny of the day: "Bug,  I'd like to add you to my professional network on LinkedIn.  - Tim"
[19:15] <vadi3> (explanation: "Clicked the wrong button on linkedin, and it blasted my entire contact list with an invite. Whoops.")
[20:04] <mrooney> So, I can change the series that a milestone is for on staging, but not on edge? How might I actually make that change?
[20:08] <mwhudson> mrooney: i guess you'll have to wait for the rollout in a week and a bit
[20:09] <mrooney> mwhudson: okay, can asking a question on launchpad get someone to manually change it? It has tons of things assigned to it but is in the wrong series unfortunately
[20:10] <mwhudson> mrooney: um, probably
[20:10] <mwhudson> mthaddon?
[20:11] <wgrant> Hmmm, one day's notice of downtime? That's not too good.
[20:53] <RAOF> Is it possible to link a bug in an Ubuntu package to an already existing upstream bug where upstream uses launchpad?
[20:53] <kiko> RAOF, funny you should mention that -- not really. you need to duplicate and then add a task to the dupe.
[20:53] <kiko> it's annoying, isn't it?
[20:54] <RAOF> Yes.
[20:55] <RAOF> Do you have the bug # for that handy, or should I be less lazy :)
[21:10] <mrooney> kiko, RAOF: yeah I have thought about that too, but if you didn't dupe and then add the task, you would have two tasks with different bug reports in the same report, it would be potentially confusing
[21:10] <mrooney> though it would be nice to treat it as upstream instead of just a different task
[21:10] <RAOF> Yes.
[21:10] <RAOF> That's what I hoped to do.
[21:11]  * wgrant looks for a Merge button.
[21:11] <wgrant> Or the dupe marking should ask if you want to copy any of the tasks over.
[21:12] <mrooney> wgrant: yes that would be nice!
[21:12] <mrooney> checkboxes for each?
[21:13] <wgrant> Yes.
[21:14] <wgrant> Or maybe it could copy all valid ones over to make things easier.
[21:14] <wgrant> But cloning invalid ones doesn't seem like a good idea.
[21:14] <mrooney> well sometimes you want them, so people can at least search and find the bug if they know what they are diong
[21:15] <mrooney> perhaps ask, checking all the valid ones by default, so you can blindly click and get decent results
[21:16] <kiko> RAOF, I think that bug is actually filed. the right thing to do is to have a "merge bugs" command for that sort of situation I think.
[21:17] <kiko> maybe merging is duping done right
[21:17] <kiko> I'm not 100% sure yet
[21:20] <wgrant> Debian's implementation of merging confuses me.
[21:25] <mrooney> I would pretty happily settle for something that auto-duped and copied over the tasks. It seems like you still want to capture that +1 duplicate in your counts
[21:25] <fta> gasp, this is becoming crazy... "PPA exceeded its size limit (11234.00 of 10240.00 MiB)"
[21:26] <LarstiQ> fta: weren't you on 5G yesterday?
[21:26] <EtienneG_home> hey guys
[21:26] <fta> LarstiQ, well... 1->3->7->3->5->10
[21:27] <EtienneG_home> knowing a Debian bug number, is it possible to find out if there is an Ubuntu bug linked to it ...?
[21:27] <kiko> EtienneG_home, yes, there is, but it's weird.
[21:27] <EtienneG_home> kiko, I don't mind weird.  I am weird.
[21:28] <kiko> https://edge.launchpad.net/bugs/bugtrackers/debbugs/464328
[21:28] <EtienneG_home> kiko, cool
[21:29] <kiko> it's a hidden feature
[21:29] <EtienneG_home> and a very useful one indeed
[21:30] <fta> LarstiQ, there are huge -dbg packages in this ppa but apparently, i'm over quota because of the previous versions piling up.. http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/pool/main/c/chromium-browser/
[21:41] <rickspencer3> how would I search for a list of bug targets using launchpad lib?
[21:41] <rickspencer3> such that I could then allow a user to choose a target and search for bugs on that target?
[21:42] <kiko> rickspencer3, it's basically a /projects search
[21:42] <wgrant> rickspencer3: You'd need to manually list all of the Projects, then their ProjectSeries, then all of the Distributions, then all of their DistroSeries, then the Distribution's DistributionSourcePackages, then all of the DistroSeries' DistributionSeriesSourcePackages.
[21:42] <kiko> rickspencer3, unfortunately I don't think there's a way to query for all 3 at once
[21:42] <wgrant> Oh dear.
[21:42] <kiko> oh, by bug target do you also mean packages?
[21:42] <rickspencer3> well, if I know the distro?
[21:43] <rickspencer3> kiko: yes, I mean packages
[21:43] <kiko> wgrant, one day I'm gonna revoke your license to our source code <wink>
[21:43] <kiko> rickspencer3, oh. is there an API to query for packages in Ubuntu, wgrant, cprov?
[21:43] <wgrant> No.
[21:43] <wgrant> There isn't.
[21:43] <wgrant> Unless you get the publishing records and work from there.
[21:43] <rickspencer3> hmmm
[21:43] <kiko> sounds like a pretty glaring omission -- it is very easy to figure that out
[21:43] <kiko> is there a bug filed?
[21:43] <wgrant> kiko: Heh.
[21:44] <wgrant> 4 months!
[21:44] <wgrant> I haven't seen one.
[21:44] <kiko> rickspencer3, if you file a bug and take it to julian he may have some favors to swap it for ;)
[21:44] <rickspencer3> hehe
[21:44] <rickspencer3> I'm all for that
[21:44] <rickspencer3> so I'm totally SOL on this one?
[21:44] <wgrant> You could getPublishedSources on the Ubuntu PRIMARY archive.
[21:45] <wgrant> But that would be terribly, terribly slow and inefficient.
[21:45] <cprov> wgrant: is it ?
[21:45] <wgrant> cprov: What? Inefficient?
[21:45] <rickspencer3> that would generate a list of all packages, more or less?
[21:45] <wgrant> A list of all versions of all packages in all distroseries.
[21:46] <wgrant> Which is likely to be an awful lot.
[21:46] <cprov> wgrant: yes, you can pass status and series
[21:46] <rickspencer3> can I do launchpad.distributions["ubuntu"].getPublishedSources?
[21:46] <wgrant> cprov: If you don't want all of the source packages in the distro, sure.
[21:46] <wgrant> I guess that could work for rickspencer3.
[21:47] <wgrant> rickspencer3: launchpad.distributions['ubuntu'].archives[0].getPublishedSources
[21:47] <rickspencer3> I just want the packages in ubuntu
[21:47] <rickspencer3> ok
[21:47] <rickspencer3> if it takes too long, I
[21:47] <wgrant> Is there a proper way to get the right archive, cprov?
[21:47] <cprov> ubuntu.main_archive.getPublishedSources()
[21:47] <rickspencer3> 'll save the results :)
[21:47] <wgrant> Ah.
[21:47] <wgrant> cprov: I was looking for primary_archive :(
[21:48] <rickspencer3> launchpad.distributions['ubuntu'].main_archive.getPublishedSources()
[21:48] <rickspencer3> ?
[21:48] <wgrant> Yes.
[21:49] <wgrant> cprov suggested getPublishedSources(distroseries=launchpad.distributions['ubuntu'].getDevelopmentSeries(), status='Published')
[21:50] <wgrant> s/distroseries/distro_series/
[21:51] <rickspencer3> k
[21:51] <rickspencer3> I'll try that
[21:52] <cprov> rickspencer3: pass "source_name='foo' " and it will return any source published matching 'foo*', since 'exact_match' defaults to False.
[21:53] <rickspencer3> where source_name is a substring of the package name?
[21:55] <cprov> rickspencer3:  try http://pastebin.ubuntu.com/137040/
[21:56] <cprov> rickspencer3: yes, the source_name is treated as substring (LIKE '%$substr%') when exact_match is omitted (or False)
[21:57] <rickspencer3> so in this way, I can allow a user to search for packages, right?
[21:57] <cprov> rickspencer3: yes
[21:57] <rickspencer3> like, if you wanted to find all bug tasks associated with notify-osd, and the user search for "osd"
[21:58] <rickspencer3> I pass that as the source_name, then allow them to pick the package from a list of results
[21:58] <rickspencer3> this is exactly what I needed!
[21:58] <cprov> rickspencer3: cool!
[21:59]  * rickspencer3 trying it now
[22:00] <rickspencer3> cprov: wgrant: worked perfectly!
[22:01] <rickspencer3> thanks a million
[22:01] <cprov> rickspencer3: you are welcome!
[22:01] <rickspencer3> kiko: it looks like my scenario is supported, just hard to grock from the docs
[22:02] <wgrant> It also breaks if you want to know about packages that don't exist any more.
[22:04] <cprov> wgrant: for this case he could play with the status argument.
[22:23] <rickspencer3> wgrant: cprov: thanks
[22:23] <rickspencer3> I am now getting back the source_package_publishing_history that I want
[22:24] <rickspencer3> but can't figure out how to get the bug_tasks for the package associated with it
[22:24] <rickspencer3> thoughts?
[22:31] <kiko> rickspencer3, I think you need a distribution_source_packaging object
[22:31] <kiko> bugtasks are linked to DSPs
[22:33] <rickspencer3> hmmm
[22:33] <rickspencer3> I want to go: distribution -> package -> bugs for that package
[22:36] <cprov> rickspencer3: ubuntu.getSourcePackage($name)
[22:36] <cprov> rickspencer3: that's annoying, you can't jump directly from a source_pub to a distribution_source
[22:36] <rickspencer3> thanks
[22:36]  * rickspencer3 tries
[22:38] <cprov> rickspencer3: ubuntu.getSourcePackage(source_pub.source_package_name)
[22:39] <cprov> rickspencer3: please file a bug requesting the implementation of source_package_publishing_history.getSourcePackage() (or similar)
[22:39]  * cprov goes out for food.
[22:39] <rickspencer3> will do
[22:39] <rickspencer3> thanks again!
[23:11] <rickspencer3> kiko: cprov-afk: wgrant: thanks guys! I'm getting back the data I wanted now
[23:11] <rickspencer3> I'll log that bug asking for a direct route tomorrow
[23:11] <rickspencer3> g'night!
[23:37] <wgrant> cprov-afk: What chance do I have of getting an argument added to IArchive.getPublishedSources() to give me all records updated since some time, rather than just those published since that time?
[23:38] <wgrant> That should let me watch all changes to the series, shouldn't it?
[23:38] <wgrant> (I need to keep track of what's superseded and what's not for reporting useful status on archive rebuilds)
[23:47] <kiko> wgrant, doesn't sound very hard
[23:52] <wgrant> kiko: I guess just take the max of all of the status dates.
[23:53] <wgrant> Since AFAICT the only fields that change are the status and the dates, and a status change triggers one of the dates to be changed.
[23:56] <cprov-afk> wgrant: overrides are new records, do you know that, right ?
[23:58] <cprov-afk> wgrant: pubshing records are only updated when they are superseded (a new one will be created), deleted or removed from the repo.
[23:59] <wgrant> cprov-afk: I know. That was my point.