[08:14] <Daviey> Hi, Is LP debian package archive published status aware?  The reason i ask, is that they all seem to be in Pending state :/
[08:15] <Daviey> s/state/status
[08:17]  * Daviey has a horrible feeling he's going to be using rmadison
[08:18] <StevenK> Daviey: We don't build Debian, we don't create build records for them, and I don't think they're published at all. What are you trying to achieve?
[08:20] <Daviey> StevenK, Use getPublishedSources, to view only published sources :)
[08:21] <Daviey> StevenK, essentially, get a package set of the latest debian sid packages via the LP api.
[08:22] <Daviey> but without the status being valid, i'm getting (what should be) Superseded packages included in my source_package_publishing_history collection .
[08:23] <Daviey> As in, multiple versions of the same package
[08:25] <StevenK> Daviey: Hm, I'm not certain you can trust the publishing status of Debian sources, given we don't publish them. Perhaps wgrant might know more, if he's around.
[08:26] <persia> My information may no longer be current, but in the past it was not unknown for LP's concept of Debian to be out of date by some time (for various complicated reasons).  This ought be better with various infrastructure improvements, but I strongly suspect it remains a low priority for investigation to ensure current data.
[08:26] <Daviey> StevenK, thanks
[08:28] <Daviey> persia, Well the data seems current, even has valid date_published... but the state is pending..
[08:28] <StevenK> persia: We have monitoring of both bits of the pipeline (debmirror and gina), so it should be okay.
[08:30] <Daviey> it would seem sensible that if we have a date_published, the state should be published... *however*, seems we don't store date_superseeded.
[08:30] <persia> StevenK: Ah, excellent.  Wonderful things happen when I don't pay attention for a few years :)
[08:30] <Daviey> Although, date_published of n+1 should surely set the date_superseeded of n
[08:31] <persia> Isn't it more complex because of the nature of Debian publication and wanna-build lag?  Also, wasn't there some work done recently to allow simultaneous parallel versions to be present in sid?
[08:32] <Daviey> Seems to be a good example: https://api.edge.launchpad.net/1.0/debian/+archive/primary/+sourcepub/1299864 & https://api.edge.launchpad.net/1.0/debian/+archive/primary/+sourcepub/1167376
[08:32] <Daviey> persia, no idea :/
[08:32] <lifeless> Daviey: please delete your edge references.
[08:32] <lifeless> edge must die
[08:33] <Daviey> lifeless, ack :)
[08:34] <lifeless> Daviey: we don't publish any of debian AFAIK
[08:34] <lifeless> we replicate it in only
[08:34] <lifeless> so its not surprising to me that none of it is published.
[08:34] <Daviey> lifeless, I wonder if natty launchpadlib should raise a Deprecation warning :)
[08:34] <wgrant> Daviey: Sources will always remain Pending.
[08:35] <wgrant> But the mirror should never be more than 12 hours out of date.
[08:35] <lifeless> Daviey: natty lplib will just use production
[08:35] <wgrant> We now have alerts in place for if that happens.
[08:35] <Daviey> lifeless, true, but why do we store date_published if we don't believe it is published?
[08:35] <wgrant> Daviey: Also, we don't track deletions at the moment.
[08:35] <lifeless> Daviey: and issue a deprecation warning too - *but* python has turned off showing deprecating warnings.
[08:35] <lifeless> Daviey: because its crazy
[08:35] <wgrant> Daviey: Because this code was written in 2004 and is INSANE.
[08:35] <Daviey> lifeless, lovely!
[08:35] <lifeless> in the membrane
[08:35] <Daviey> wgrant, lol
[08:36]  * Daviey raises a big scream.
[08:37] <Daviey> So, other than client side processing - is there any way of getting a source_package_publishing_history collection of just the latest debian source packages?
[08:37] <wgrant> What does that mean?
[08:37] <lifeless> what do you want to achieve?
[08:38] <mneptok> peace with honor. peace in our time.
[08:38] <mneptok> oh, and grilled cheese.
[08:38] <jpds> mneptok: honour*
[08:38] <Daviey> wgrant, as an example, something like http://pb.daviey.com/gIaE/
[08:38] <wgrant> Daviey: The import mainly serves to get the files into LP, and to notify services of new Debian uploads.
[08:39] <Daviey> and only return the highest debian version source.
[08:39] <mneptok> jpds: je parle Francais, aussi.
[08:39] <wgrant> Daviey: That's not what you want to achieve.
[08:39] <wgrant> That's a way to achieve it.
[08:40] <Daviey> wgrant, ok..
[08:41] <wgrant> Daviey: I doubt that you want to print out a list Debian source package names in a fairly slow way.
[08:41] <wgrant> You presumably have some use for that sort of information.
[08:41]  * persia suspects yet another implementation of mdt, but is only guessing
[08:42] <wgrant> That is also my suspicion.
[08:43] <Daviey> wgrant, yeah - that was just an example of trying to achieve a valid source package collection
[08:43] <persia> Daviey: What's your large-scale project, of which this is merely stropping the razor prior to wetting the yak?
[08:44] <Daviey> persia, lol.. compare two way delta between debian and ubuntu for a given package set.
[08:45] <wgrant> Hmm, where have I seen that before...
[08:45] <persia> mdt *does* just that.
[08:45] <persia> wgrant: Would you mind adding the server packageset and passing Daviey a URL :)
[08:45] <wgrant> Daviey: See the note at the bottom of http://qa.ubuntuwire.org/multidistrotools/
[08:46] <wgrant> And also see the example pages.
[08:46] <persia> Daviey: For more advanced information, you may want to look also at PET
[08:47] <persia> Daviey: http://pet.alioth.debian.org/
[08:47] <persia> (would need tweaking to also show Ubuntu and LP bug count, but those changes would be welcomed by some PET using teams in Debian)
[08:49] <Daviey> Hmm.. One of the issues that multidistrotools seems to have, is that it's not easy to see /what/ is the delta; without manually looking at the changelog and parsing the difference in your head.
[08:50] <persia> Could add a link to patches.ubuntu.com
[08:50] <wgrant> Do you have some ideas for improving that?
[08:50] <wgrant> There should already be such a link.
[08:50] <persia> Or a link to merges.ubuntu.com
[08:50] <wgrant> unless I disabled that for performance reasons.
[08:51] <wgrant> Yup, it's even bold.
[08:51] <persia> I think you disabled it for performance reasons: I see PTS, BTS, changes, buildlog, packages.u.c, LP, LP bugs, LP builds, LP changelogs
[08:51] <Daviey> wgrant, parsing the changelog looking for changes until version = natty.version, for example
[08:51] <persia> Ah, I'm looking in the wrong place.
[08:52] <Daviey> then in reverse, changelogs in natty,until version string doesn't contain ubuntu.
[08:52] <wgrant> Daviey: You want to see the changelog entries from the LCA?
[08:53] <persia> LCA?
[08:53] <wgrant> Latest common ancestor.
[08:53] <wgrant> MRCA, I guess it should be.
[08:53] <Daviey> wgrant, yes
[08:53] <persia> I'm not sure I comprehend the semantic difference between "latest" and "most recent", but I'll take your word for it.
[08:55] <wgrant> Daviey: So, Launchpad's derivation functionality will do this sort of thing within a few months. It's not clear when that will be applied to Debian->Ubuntu, but it should happen soon.
[08:55] <Daviey> wgrant, Ah!
[08:55] <wgrant> persia: Nothing, but MRCA seems to be the conventional term.
[08:55] <Daviey> That sounds peeeeerfect!
[08:56] <wgrant> Daviey: It will basically do mdt in LP.
[08:56] <wgrant> With packageset filtering.
[08:56] <wgrant> And diffs between the base and the Ubuntu and Debian versions.
[08:56] <wgrant> Which could have the changelog extracted if you so desire.
[08:57] <Daviey> I have a function doing that, both ways - but i was trying to make it db backed to not hammer the api and changelog servers every time i run it.
[08:57] <Daviey> wgrant, seems exciting times!
[08:57] <persia> wgrant: Will that also be replacing the non-LP bits of MoM and patches?
[08:59] <Daviey> wgrant, Is there a bug or blueprint i can track for that?
[08:59] <wgrant> persia: Neither is directly in scope, AIUI. But I hope that MoM will be replaced by UDD, and patches can be easily replaced by LP even now.
[09:00] <wgrant> Daviey: I don't know of any. But there is http://dev.launchpad.net/LEP/DerivativeDistributions
[09:00] <persia> patches-replaced-by-LP -> that's probably worth doing sooner than later if it's ready, simply to reduce redundancy and start client migration (there are a bundle of clients).
[09:01] <wgrant> persia: A good experience for that depends on some of the derivation work that is yet to be done.
[09:01] <persia> MoM-replaced-by-UDD -> how does that work?  common-ancestor-import-branches-from-Debian and looms/pipelines/whatever to dig around at the diff?
[09:01] <persia> Heh.  That makes sense.
[09:01] <wgrant> persia: I believe that's the intention.
[09:02] <wgrant> I hope that looms become more sensible soon.
[09:02]  * Daviey pity's the person that tries to announce that
[09:02] <wgrant> Daviey: I imagine it'll be quite a while off :/
[09:02] <persia> Daviey: Why?  There's no reason one can't implement a get-merge (or whatever the script is called) that uses UDD to provide a compatible experience.
[09:02]  * persia doesn't tend to like the merges that come from working with MoM anyway
[09:18] <didrocks> hey hey
[09:18] <didrocks> just a short question on bug expiration
[09:18] <didrocks> if I have three bug tasks on a bug
[09:18] <didrocks> two of them are incomplete and one is New
[09:18] <didrocks> will the bug expire?
[09:19] <wgrant> To qualify for expiration, the bug and its bugtasks meet the follow conditions:
[09:19] <wgrant> ...
[09:19] <wgrant>         3. The bug does not have any other valid bugtasks.
[09:20] <wgrant> I think New should count as a valid bugtask.
[09:20] <wgrant> Let me check.
[09:20] <didrocks> sure :)
[09:21] <Daviey> persia, We both know there are people that will get upset if the traditional development model is changed in any way.
[09:22] <persia> There's changes and there's changes.
[09:22] <lifeless> on
[09:22] <lifeless> oh
[09:22] <lifeless> that reminds me
[09:22] <persia> MoM has issues: other data sources are always welcome, and MoM has had improvements/changes in the past to accomplish various goals.
[09:22] <wgrant> didrocks: It looks like any status other than Invalid, Incomplete and Won't Fix is sufficient to hold a bug open. Even Expired...
[09:22] <lifeless> deryck is open to the 'new' link becoming 'untriaged' with a broader than just new list for untraiged bugs
[09:22] <didrocks> wgrant: excellent, thanks for the answer :)
[09:23] <wgrant> didrocks: So no, the bug should not expire.
[09:23] <lifeless> e.g incomplete-with-response, confirmed, status undecided would all count
[09:23] <didrocks> thanks wgrant
[09:23] <persia> On the other hand, changes like making me wait 30 times as long to download a package when I don't care about the metadata or history in the context I'm getting the package gets in the way.
[09:24] <persia> The key is flexibility: as long as there is *support* for various ways of doing things, people are happy, and some ways of doing things can become deprecated once nobody uses them.
[09:25] <didrocks> wgrant: so, in this bug: https://bugs.launchpad.net/unity/+bug/661097
[09:26] <didrocks> wgrant: will the unity upstream/downstream tasks can expire?
[09:26] <wgrant> didrocks: No.
[09:26] <didrocks> wgrant: ok, the status is "global"
[09:26] <wgrant> didrocks: Right. A task will only expire if there are no other unexpirable tasks.
[09:27] <didrocks> wgrant: excellent, that was the answer I was expecting. Thanks! ;)
[10:44] <Daviey> What is the process for reporting spamming users?
[10:45] <Daviey> Someone i know (a non-spammer) account seems to be spamming LP bugs.
[10:45] <Peng> https://answers.launchpad.net/launchpad/+addquestion I believe
[10:45] <Daviey> He's asleep at the moment...
[10:48] <cody-somerville> Daviey, Whats the account name? We may have already noticed it.
[10:48] <lifeless> if this is nickj
[10:48] <lifeless> I've suspended it
[10:48] <Daviey> yeah..
[10:48] <Daviey> ah
[10:48] <Daviey> https://answers.launchpad.net/launchpad/+question/146394
[10:49] <Daviey> thanks lifeless
[10:51] <lifeless> thanks for alerting us
[10:51] <lifeless> ngight
[10:52] <Daviey> nn lifeless
[11:42] <mdz> is staging really still updating, or is there a problem with it?
[11:47] <wgrant> mdz: The normal code updates failed last week due to its data being too old. We decided we'd wait for the weekend database restore to fix that. But it turns out that had been automatically disabled after several failed code updates, or something like that.
[11:48] <wgrant> However, the manual restore that was started yesterday should just about be finished now.
[11:48] <mdz> wgrant, thanks
[18:38] <Hmarzz> Is there a launchpad representative that I could speak with about an issue with the SSO service?
[19:43] <gnomefreak> seb128: all gnome panels disappear, the window boarders are gone. you cant click on any window and use it. for example i had 2 terms open and i can switch between them but i can not use any commands and such
[19:43] <gnomefreak> oh damn
[19:47] <jcsackett> gnomefreak: was that "oh damn" a sign of wrong channel/window?
[19:47] <gnomefreak> jcsackett: yeah wrong channel
[19:48] <jcsackett> dig. :-)
[19:49] <gnomefreak> some how i went from /win 17 to /win 19 while typing
[21:22] <kklimonda> hey, I have a problem pushing branch to LP. The first time I try I get this error: http://paste.ubuntu.com/570777/
[21:22] <kklimonda> the second time I try to push it just pushes infinitely
[21:28] <kklimonda> it looks like it's trying to first pull all commits from the gtkmm trunk branch (which is a clone of upstream git repo) but my branch have nothing to do with it.
[21:35] <sinzui> kklimonda: yes it is doing that
[21:36] <sinzui> kklimonda: the formats are incompatible so bzr is trying to put everything there
[21:37] <sinzui> I think you need to update the branch format. let me check the branch you want to stack this on
[21:38] <kklimonda> do you have any solution I could use? :)
[21:39] <sinzui> yuck https://code.launchpad.net/~vcs-imports/gtkmm/main is using an obsolete format
[21:39] <sinzui> kklimonda: I think I want to update Lp to 2a, which is what you probably have since it has been standard for almost a year
[21:40] <kklimonda> makes sense :)
[21:41] <sinzui> kklimonda: the other option is to branch from lp:gtkmm, to get an older format. merge your changes into the second branch, then push
[21:41] <kklimonda> sinzui: the problem is I don't branch from the lp:gtkmm
[21:42] <kklimonda> sinzui: ubuntu desktop team uses the same project for pushing packaging-only branches
[21:42] <kklimonda> I think I could branch from lp:~ubuntu-desktop/gtkmm/ubuntu and that should fix it.
[21:43] <sinzui> kklimonda: yes
[21:50] <kklimonda> no, it didn't work after all
[21:50] <kklimonda> maybe if I try to push without my commits first..
[21:50] <kklimonda> no, still the same error
[22:59] <mhr3> hey guys, is something wrong with recipes? i get an oops every time i click request build
[23:00] <mhr3> for example (Error ID: OOPS-1879EA1560)
[23:08] <wgrant> mhr3: It sounds like you're not in the recipe beta testing team. Try joining https://launchpad.net/~launchpad-recipe-beta
[23:09] <mhr3> wgrant, that's it, thanks
[23:10] <wgrant> mhr3: Also, any particular reason you're still using edge?
[23:10] <mhr3> wgrant, firefox remembers it there :)
[23:11]  * micahg has lots of old edge URLs in his history
[23:14] <wgrant> Mine are almost all gone.
[23:38] <lool> jml: leankit credentials > the blog post says they have been updated, I see "guest@canonical.com" and "guest" and this doens't work