[00:06] <mwhudson> thumper: heh
[00:07] <thumper> mwhudson: want to review it?
[00:07] <mwhudson> thumper: yeah alright
[00:07]  * thumper sends
[00:13] <thumper> mwhudson: sent, now just flowing through the ether
[00:16] <mwhudson> thumper: ok
[00:25]  * thumper heading afk for a while
[00:28] <thumper> mwhudson: hmm, my bzr send caused an oops :(
[00:28] <thumper> I'll look at that later
[00:28] <thumper> mwhudson: did a manual propose
[00:29] <mwhudson> ok
[00:30] <mwhudson> thumper: i'm going to get this script running with spm and then break for lunch though
[00:30] <spm> mwhudson: it may take a while; that's a huge patch for my itsy network connection.
[00:31] <mwhudson> spm: 75k?
[00:32] <spm> mwhudson: your irony detector is broken. ;-)
[00:32] <mwhudson> i see :)
[00:32] <mwhudson> it needs lunch too, it seems
[00:32] <spm> that'd do it.
[01:40] <wgrant> Uhoh.
[01:40] <wgrant> Some bits of LP use string sorting on version numbers.
[01:40] <wgrant> (DistributionSourcePackageView.active_series is the most obvious so far)
[01:58] <mwhudson> i guess we've got one more release before that bites us on the arse?
[02:25] <wgrant> mwhudson: No. Lucid exists now.
[02:25] <wgrant> eg. see https://edge.launchpad.net/ubuntu/+source/dpkg
[02:26] <wgrant> Just display glitches, fortunately.
[02:26] <wgrant> But still had me confused that Lucid wasn't yet initialised.
[02:28] <mwhudson> wgrant: oh yeah
[03:11]  * Ursinha looks at spm
[03:11] <spm> Ursinha: yo!
[03:11] <Ursinha> :)
[03:12] <Ursinha> spm, hey :) are you busy now?
[03:12] <Ursinha> terribly-dying busy?
[03:12] <spm> mind you - that's an impressive 15000km stare you have :-D
[03:12] <Ursinha> hahaha
[03:12] <spm> Ursinha: nothing that can't be put aside; what's up?
[03:12] <Ursinha> spm, it's a simple question, that maybe has a simple answer :)
[03:13] <Ursinha> spm, I see emails of a garbo-hourly script failing
[03:13] <Ursinha> do you know why is it happening?
[03:13] <spm> hahahahaa oh the irony.
[03:13] <Ursinha> why? :)
[03:13] <spm> I was just chasing that and emailed stub about 15 mins ago :-)
[03:13] <Ursinha> oh, hehe
[03:13] <spm> afaict, it is working; but isn't logging to scriptacivity.
[03:13] <Ursinha> hmmm, I see
[03:14] <spm> there's an error in the log file; that may be glitching the "success"; but locks are opened and removed; so it looks good.
[03:14] <spm> checkwatches was hung - if that's the next question? :-)
[03:15] <wgrant> Of course. It's checkwatches. It hasn't worked for ages.
[03:38] <thumper> spm: how's our script going?
[03:39] <spm> thumper: branch-distro ? you've not read mwh's email?
[03:39] <mwhudson> thumper: it's not :(
[03:39] <thumper> ah
[03:39] <thumper> bum
[03:41] <mwhudson> yes
[04:05] <thumper> mwhudson: so... my review?
[04:05] <mwhudson> thumper: sorry forgot, am on it now
[04:05] <mwhudson> or would be if launchpad was behaving
[04:06] <thumper> mwhudson: so... my oops with send oopsed due to a branch lock
[04:07] <mwhudson> thumper: bzr lock or database lock?
[04:07] <mwhudson> "!" either way mind
[04:07] <thumper> bzr lock
[04:07] <thumper> mwhudson: the scanner acquires a branch lock
[04:07] <thumper> so...
[04:07] <mwhudson> no it doesn't
[04:07]  * thumper thinks
[04:07] <thumper> ah
[04:07] <mwhudson> or at least, it's only a read lock
[04:07] <thumper> I'm pretty sure it does
[04:07] <mwhudson> it access the branch over read only http
[04:07]  * thumper looks
[04:08] <mwhudson> if it can obtain an exclusive lock over that transport something very strange is going on! :)
[04:08] <thumper> yep, lock-read
[04:08] <thumper> so...
[04:08] <thumper> how does that work then?
[04:09] <mwhudson> a read lock just means that the bzr client assumes the branch won't change under it
[04:09] <mwhudson> it caches revnos & probably some other things
[04:10] <thumper> so...
[04:10] <mwhudson> thumper: i would guess the lock was from the puller
[04:10] <thumper> hmm...
[04:10] <thumper> possibly
[04:11] <thumper> I guess there isn't much else that tries to lock it
[04:12] <lifeless> mwhudson: no, it doesn't assume it won't change
[04:12] <lifeless> mwhudson: it presents a stable view of the data to the holder of the read lock
[04:13] <mwhudson> er i guess that's more accurate yes
[04:13] <lifeless> e.g. successive calls to last_revision() are the same within a read lock
[04:13] <lifeless> old formats did mutually exclude writers
[04:13] <lifeless> when we used os locks for reads of branch/repository
[04:14]  * thumper goes to purchase many pizzas to feed a gaggle of girls
[04:14] <mwhudson> thumper: i'll have your branch reviewed when you get back i hope
[04:44]  * thumper is back
[04:47] <mwhudson> thumper: ok i was wrong then
[04:47] <thumper> mwhudson: :)
[04:47] <thumper> I did look though
[04:47] <mwhudson> thumper: the only concern i have really is what it will look like if the attachment isn't actually a diff
[04:48] <thumper> mwhudson: the diff formatter looks at the first character
[04:48] <thumper> to decide how to colour it
[04:48] <mwhudson> thumper: oh ok
[04:48] <thumper> but yes
[04:48] <thumper> I did consider possibly doing text/plain different
[04:49] <mwhudson> thumper: what would happen with say image/jpeg?
[04:49] <mwhudson> do they get filtered somewhere else?
[04:49] <thumper> but decided against it
[04:49] <thumper> the diff formatter is pretty dumb
[04:52] <thumper> most likely you'll get line numbers and everything plain
[04:52] <thumper> for things that aren't actually diffs
[05:03] <thumper> mwhudson: yes, not shown
[05:03] <mwhudson> thumper: cool
[05:03] <thumper> mwhudson: that is a different bug
[05:03] <mwhudson> :)
[05:03] <thumper> or feature
[05:03] <mwhudson> not displaying random binaries as text is definitely a feature
[05:10] <thumper> mwhudson: there is a filter on text/plain, text/x-diff, text/x-patch
[05:10] <mwhudson> cool
[05:10]  * mwhudson EOWs
[05:11] <thumper> mwhudson: have a good weekend
[05:11] <mwhudson> thumper: you too!
[05:32] <jtv> stub: I think I've got my memory hog.  Essentially the same as in phase 2 of the algorithm.  Generalizing the same solution to re-apply it.  Care to review it in a few?
[06:26] <jtv> stub: got my branch ready... would you be willing to (1) do a test run and (2) review it?
[06:26] <jtv> stub: you already know a lot of what goes on in there, so you're probably the best reviewer at this point.
[06:36] <stub> k
[06:36] <stub> jtv: k
[06:37] <stub> jtv: What was the branch again?
[06:37] <stub> http://bazaar.launchpad.net/~jtv/launchpad/scale-message-sharing-migration/
[06:38] <stub> jtv: I'll need to know the last unreviewed revision too
[07:11] <jtv> hi henninge
[07:11] <jtv> stub: I must be off... any news?
[07:50] <henninge> Hi jtv, I somehow missed your hailing ...
[07:58] <jtv> henninge: never mind, I'm not here
[07:59] <henninge> jtv: oh right, that's why I didn't notice you, then ... ;)
[07:59] <jtv> henninge: no, no word
[08:02] <henninge> jtv: I'll be relocating now
[08:27] <adeuring> good morning
[09:34] <mrevell> Morning!
[09:49] <henninge> Hello!
[09:49] <henninge> Does anybody have an idea what this might be about? http://paste.ubuntu.com/304910/
[09:50] <noodles775> henninge: usually it means that you're not currently logged in?
[09:50] <henninge> noodles775: oh, that is true (that I am not logged in)
[09:50] <noodles775> great.
[09:50] <henninge> noodles775: I am doing this in a pagetest
[09:51] <noodles775> henninge: yep, so pop a login('foo.bar@canonical.com') before it (or with relevant user).
[09:51] <stub> henninge: Some code expects you to be logged in, such as something trying to security wrap an object.
[09:54] <jml> good morning
[09:54] <henninge> noodles775, stub: Thank you, that was it. I needed to logout, too, so that the rest of the test can run as before.
[09:54] <noodles775> np.
[11:59] <maxb> Is there a standard procedure for updating the version number of Launchpad in the Launchpad sourcecode documented anywhere?
[12:01] <salgado> maxb, I don't think so.  do you just want to know how to do it or are you planning to create such doc if one doesn't exist?
[12:01] <maxb> A bit of both. Mainly I think it sucks that some places still say 2.2.3
[12:02] <salgado> really?  where does it say that?
[12:03] <salgado> all places which mention the release should be using modules/canonical.launchpad.versioninfo/release
[12:04] <maxb> salgado: setup.py
[12:04] <salgado> and that call I pasted above would read the version number from /version.txt
[12:12] <salgado> maxb, would it be possible to change canonical/launchpad/versioninfo.py to read the version number from setup.py?  that way we'd have that info in only one place
[12:12]  * wgrant wouldn't mind another set of eyes on bug #54730.
[12:12] <mup> Bug #54730: launchpad buildd abort does not work as expected <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/54730>
[12:13] <wgrant> Although I guess there are few left who know lp-buildd :(
[12:16] <maxb> salgado: How about doing this in setup.py instead: ?
[12:16] <maxb> import imp
[12:16] <maxb> versioninfo_module = imp.load_source('setup_py_versioninfo',
[12:16] <maxb>         'lib/canonical/launchpad/versioninfo.py')
[12:16] <maxb> __version__ = versioninfo_module.release
[12:19] <salgado> that adds one more level of indirection
[12:19] <salgado> the actual version would go version.txt -> versioninfo -> setup.py
[12:19] <salgado> if we move the version to setup.py, it'd go setup.py -> versioninfo.py
[12:20] <maxb> The problem with putting it in setup.py is that you need to be able to load it without executing any of the setuptools gumph
[12:21] <maxb> I guess we could move almost all of the current setup.py inside an if __name__ == '__main__'
[12:22] <salgado> yeah, that'd work
[12:24] <wgrant> How do you get at setup.py from versioninfo.py?
[12:25] <maxb> Same way you get at bzr-version-info.py ?
[12:26] <wgrant> Ah. I see.
[12:27] <maxb> Though maybe rather than moving all of setup.py into an if-block, it would be neater to have setup.py and c.l.versioninfo both get the version from a oneliner lp_version_info.py ?
[14:14] <henninge> Ursinha: what are you trying to achieve?
[14:14] <Ursinha> henninge, good!
[14:15] <Ursinha> henninge, I'm trying to add a Last Edited column to the +translations pages, like this one: https://translations.launchpad.dev/alsa-utils/trunk/+translations
[14:16] <henninge> oops, no dev running here atm
[14:16] <henninge> Ursinha: I think you are on the wrong track
[14:16] <Ursinha> so I've added it to the template, and am trying to use the fmt:datetime do display the date the same way it's displayed in this one: https://translations.edge.launchpad.net/ubuntu/karmic/+lang/pt_BR/+index
[14:16] <henninge> Ursinha: you are trying to format a datetime object
[14:16] <Ursinha> henninge, hmm
[14:16] <Ursinha> go ahead
[14:16] <henninge> wait
[14:17] <Ursinha> sure :)
[14:18] <henninge> so, what goes behind the colon (:) is not what you are trying to format, but *how*
[14:18] <henninge> let me look up what it's called again
[14:18] <Ursinha> henninge, I know that
[14:18] <Ursinha> :)
[14:19] <Ursinha> henninge, the point is what do I have to do for it to use the fmt:datetime
[14:19] <Ursinha> I couldn't find out what the other page does that I'm not doing
[14:19] <Ursinha> I'm getting a traversal error
[14:19] <henninge> Ursinha: sorry, I just saw that there is actually a formatter called datetime, didn't know that
[14:19] <Ursinha> :)
[14:20] <henninge> Ursinha: show me the code
[14:20] <henninge> ;)
[14:20] <Ursinha> henninge, sorry, sometimes I assume that you guys are translations code gods and know everything about it
[14:20] <Ursinha> henninge, let me try something else here, a moment, please :)
[14:20] <henninge> I have actually found out how to use a formatter from python and found that pretty cool
[14:20] <henninge> ;-)
[14:21] <Ursinha> henninge, mind to explain? :)
[14:21] <henninge> I am just saying that I am exploring these things myself in varying depths
[14:24] <Ursinha> henninge, oh, I see :)
[14:26] <Ursinha> henninge, I think I found out the problem
[14:26] <Ursinha> I have to have a Datetime object for it to let me use the formatter
[14:27] <Ursinha> I may be wrong, but so far is my best guess
[14:27] <henninge> Ursinha: I am pretty sure you need a Datetime object!
[14:27] <henninge> ;-)
[14:27] <henninge> Ursinha: what were you trying to use the formatter on?
[14:28] <Ursinha> henninge, in what I thought that was a Datetime object, but realize it's not :)
[14:28] <henninge> ah
[14:28] <Ursinha> realizeD
[14:28] <henninge> Ursinha: that's excusable ;-)
[14:28] <Ursinha> henninge, hehe :)
[14:28] <henninge> sinzui: ping
[14:29] <sinzui> hi henninge
[14:29] <henninge> hi sinzui
[14:29] <henninge> sinzui: I am trying to triage bug 462891
[14:29] <mup> Bug #462891: TraversalError on +export <oops> <Launchpad Translations:New> <https://launchpad.net/bugs/462891>
[14:29] <henninge> sinzui: the oops happens when trying to access user/preferredemail/email
[14:30] <sinzui> it is not visible
[14:30] <sinzui> the app genuinely does not have permission to see it
[14:30] <henninge> sinzui: does that happen when the user hides his/her email address?
[14:31] <henninge> sinzui: although I tried that and it did not reproduce
[14:32] <sinzui> henninge: Yes. In many mail/login usage, we use something link removeSecurityProxy(user.preferredemail).email
[14:32] <sinzui> henninge: in this tales example. we simply do not have permission to show it. we should not
[14:33] <henninge> sinzui: ok
[14:33] <henninge> sinzui: is there an easy way to check in tales if we have that permission of not?
[14:33] <sinzui> |nothing helps
[14:34] <sinzui> it swallows exceptions
[14:34] <henninge> sinzui: good idea, thanks
[14:37] <sinzui> henninge: in tales you might also do
[14:37] <sinzui>           <tal:visible-email
[14:37] <sinzui>             condition="context/owner/preferredemail/required:launchpad.View">
[14:37] <sinzui>             (<span tal:replace="context/owner/preferredemail/email" />)
[14:37] <sinzui>           </tal:visible-email>
[14:37] <henninge> sinzui: cool, thanks
[14:43] <Ursinha> henninge, so, I think I'm missing something
[14:43] <Ursinha> it seems the thing I'm returning is a datetime object
[14:43]  * Ursinha just thought about make harness
[14:43] <Ursinha> anyway, it seems the object is correct
[14:43] <Ursinha> but I may be missing defining the property somewhere
[14:45] <Ursinha> henninge, are you dying busy? :)
[14:46] <henninge> Ursinha: sorry. Still trying to triage (reproduce) that traversal error
[14:47] <henninge> Ursinha: define which property?
[14:47] <Ursinha> the lastChangedDate that I want to add in that page
[14:48] <henninge> Ursinha: can you push the branch and let me have a look at it?
[14:48] <Ursinha> henninge, sure, but it's a mess, just a warning :)
[14:49]  * henninge is used to messes
[14:52] <BjornT_> mars, gary_poster: can any of you take a look at https://code.edge.launchpad.net/~bjornt/lazr-js/download-cache/+merge/14220? it's a quick fix, so that people won't have to know how to set up a download-cache
[14:53] <gary_poster> BjornT_: on call, will check back
[14:53] <mars> BjornT_, on a call for a bit
[14:53] <mars> :)
[14:54] <henninge> Ursinha: I cannot set the bug 462891 to triaged or set its importance. I have insufficient permissions for that.
[14:54] <mup> Bug #462891: TraversalError on +export <oops> <Launchpad Translations:New> <https://launchpad.net/bugs/462891>
[14:55] <henninge> Ursinha: ???
[14:55] <Ursinha> henninge, how come?
[14:55] <henninge> dunno
[14:55] <henninge> The following errors were encountered:
[14:55] <henninge>     * Only Bug Supervisors may change status to Triaged.
[14:55] <Ursinha> henninge, try again
[14:55] <sinzui> henninge: are you logged in
[14:55] <Ursinha> eh eh
[14:55] <henninge> sinzui: oh, I was fooled
[14:56] <henninge> Ursinha: ^
[14:56] <Ursinha> there should be something showing you're not logged in
[14:56] <Ursinha> like a different color
[14:56] <Ursinha> don't know
[14:56] <Ursinha> henninge, was that the problem?
[14:56] <henninge> I logged myself out in another tab
[14:56] <henninge> but the bug page still looked like I was logged in ...
[14:57] <Ursinha> henninge, oops :)
[14:58] <Ursinha> henninge, happens to me sometimes, and my brain always fail to realize that could be this simple before panicking
[14:58] <Ursinha> henninge, btw, thanks for triaging that bug
[14:58] <henninge> Ursinha: np
[15:03] <henninge> Ursinha: btw, where those the only two occurances of that particular OOPS? I have not been able to reproduce the bug and it would be interesting to know how often it occurs.
[15:03] <henninge> s/where/were/
[15:03] <Ursinha> henninge, we had about 40 a day since I've reported the bug
[15:03] <henninge> oh!
[15:05] <Ursinha> henninge, see here: https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2009-10-29.html#exceptions
[15:05] <Ursinha> for example
[15:15] <henninge> Ursinha: oops.py should display the *account* name (which is unique), not the display name, which may appear gazillion times
[15:15] <henninge> Ursinha: who maintains oops.py?
[15:16] <Ursinha> henninge, matsubara-afk does
[15:16] <henninge> Ursinha: is there a branch somewhere?
[15:16] <Ursinha> henninge, yes, a moment, please
[15:30] <mars> beuno, on a merge proposal, why is there a [Review] link and a [Claim Review] button?
[15:30] <henninge> Ursinha: did you ever push that branch of yours?
[15:30] <Ursinha> henninge, pushing, pushing
[15:30] <Ursinha> :)
[15:30] <beuno> mars, I wish I had a nice answer to that
[15:30] <Ursinha> danilos is alive, I'll rip him them :P
[15:31] <Ursinha> thanks henninge :)
[15:32] <henninge> Ursinha: oh, that would be nice. I have guests tonight and wanted to cut it short. Is that ok with you?
[15:33] <Ursinha> henninge, if it's fine with danilos than it's fine by me
[15:33] <Ursinha> :)
[15:34] <henninge> Ursinha: Oh, I thought you were already talking to him
[15:34] <danilos> henninge, she was, I'll be happy to take on bug 462891 (we should always show that address, so removeSecurityProxy should do)
[15:34] <mup> Bug #462891: TraversalError on +export <oops> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/462891>
[15:35] <danilos> henninge, however, I am worried that this might happen when there's no preferred email as well
[15:35] <henninge> danilos: I was not even trying to fix it, just to reproduce it
[15:36] <danilos> henninge, as you can see, we are trying to traverse into None.email, so that's probably why it happens
[15:37] <henninge> danilos, Ursinha: actually, I thought we were still talking about Ursinha's fmt:datetime problem ...
[15:38] <danilos> henninge, heh, I am not sure about what we are talking about now :)
[15:49] <Ursinha> danilos, I was asking henninge's help because I thought you weren't there, but about the bug I'm fixing, not the bug henninge is
[15:49] <Ursinha> :)
[15:49] <henninge> I am a bug?
[15:50] <danilos> henninge, no, you just look like one
[15:54] <rockstar> abentley, hi
[15:54] <abentley> rockstar: Hi.
[15:55] <rockstar> abentley, so, I'm trying to compare to jobs, using your implementation of __eq__ and it's complaining that context is a ForbiddenAttribute - is that by design?
[15:56] <abentley> rockstar: No.
[15:56] <rockstar> abentley, so it's okay that I add it to the interface to be accessible?
[15:57] <abentley> rockstar: Doesn't forbidden mean it's not even on the underlying model object?
[15:57] <rockstar> abentley, I don't think so.
[15:58] <abentley> rockstar: I thought it was unauthorized if you don't have permission, forbidden if it doesn't exist.
[15:58]  * rockstar checks
[15:59] <rockstar> abentley, no, if if rSP an object, context is there.  In fact, the context should always be there in this case, since the context is the BranchJob
[16:00] <danilos> sinzui, salgado-lunch, hey, just to confirm one thing: we can have logged in users into Launchpad with no preferred email set or no? (re bug 462891)
[16:00] <mup> Bug #462891: TraversalError on +export <oops> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/462891>
[16:00] <abentley> What is rSP?
[16:00] <danilos> abentley, removeSecurityProxy?
[16:00] <sinzui> danilos: I do not think that is possible.
[16:00] <abentley> Okay, so expose it on the API.
[16:01] <sinzui> danilos: I spoke to henninge about that
[16:01] <rockstar> abentley, great, thanks.
[16:01] <sinzui> danilos: User can set the email address to be hidden and we honour it
[16:01] <danilos> sinzui, I know you did, but the thing is that we try to show email only to users themselves, and we should have privileges to do it
[16:02] <danilos> sinzui, this page is rendered when user is requesting a download, and we display email address so they know where they'll get an email when the export is ready for download
[16:02] <sinzui> danilos: have you tried the proven tales fraement to access a hidden email address
[16:02] <danilos> sinzui, however, the traversal error tries to get email property on None, meaning that preferredemail is None, and not inaccessible
[16:03] <sinzui> danilos: hmm
[16:03] <danilos> sinzui, at least that's how I read it, maybe I need to look into preferredemail implementation
[16:03] <sinzui> danilos: I still state that the login server should never let a user login without a preferred email address. I do not think anyone can login without creating a profile, and that step ensures a preferred email address.
[16:04] <sinzui> danilos: do we know the user?
[16:04] <danilos> sinzui, we've had a few bugs with person/account split; this is happening with more than one user, and we haven't seen this ever before
[16:06] <sinzui> I see the user just came from login
[16:06] <sinzui> I cannot believe we let that launchpad id exist
[16:08] <danilos> sinzui, yeah, that was exactly my opinion when I saw the exclamation mark in the user ID, but that might be part of the displayname
[16:09] <sinzui> danilos: i think we need to query the person table of staging to see if this a real user. I hope that id is person, not account
[16:12] <sinzui> danilos: He has an email address https://edge.launchpad.net/~iqt
[16:13] <danilos> sinzui, yeah, so I guess you were right about preferred email being returned as None when it's hidden (though, shouldn't it be hidden from us as well?)
[16:14] <sinzui> danilos: You are special. You are a registry admin
[16:15] <sinzui> danilos: That means your related software report is 100% crack
[16:15] <danilos> sinzui, however, I see no person for this account
[16:15] <danilos> sinzui, heh, right :)
[16:15] <sinzui> danilos: This page does not who accounts. only person
[16:15] <danilos> sinzui, I am looking at staging DB
[16:16] <sinzui> danilos: there is only one page that can show an account and only a LOSA can see it
[16:16] <sinzui> danilos: the account was created on the 27. maybe staging is old
[16:16] <danilos> sinzui, staging DB seems outdated though
[16:16] <danilos> sinzui, yep
[16:30] <danilos> sinzui, just fyi, looking at the code, preferredemail has no restrictions by whether an address is hidden or not; and, all of these seem to have just logged in before that, and the account was created just a few minutes ago; I am guessing that launchpad_auth_master has some data that launchpad_main_master still doesn't
[16:35] <henninge> danilos, Ursinha: Enjoy the weekend, I am off now!
[16:35] <sinzui> danilos: thank makes sense. We had a number is similar oopses a few months ago where there as a 20 minute lag
[16:35] <Ursinha> bye henninge :) you too
[16:35] <henninge> danilos: you'd better get all well!
[16:37] <danilos> henninge, cheers
[17:02] <sinzui> Chex: ping
[17:03] <Chex> sinzui: hello there
[17:04] <sinzui> Chex: I want to test the product-release-finder on staging, but it just occurred to me that I do not know if the fix was pushed there this week
[17:05] <Chex> sinzui: ok, was this a cowboy fix, or a revno release
[17:05] <Chex> ?
[17:05]  * sinzui loks for revno
[17:07] <sinzui> no it did not arrive
[17:08] <sinzui> Chex: do you know what is blocking staging from a code update?
[17:08] <BjornT_> danilos: still there?
[17:11] <BjornT_> danilos: those windmill errors are strange, i don't know what are causing them. you can merge lp:~bjornt/launchpad/bug-430702 to work around them
[17:12] <Chex> sinzui: I am not sure, let me check
[17:14] <danilos> BjornT_, ok, thanks
[17:15] <danilos> BjornT_, also, thanks for looking into this, very much appreciated
[17:31] <rockstar> abentley, what would it take to teach the scanner about bzr pipelines and the next and prev pipes?
[17:31] <rockstar> abentley, (in the context of setting pre-req branches)
[17:31] <abentley> rockstar: A database patch.
[17:32] <abentley> rockstar: Why do you ask?
[17:33] <sinzui> Chex: I think I am confused by the version of code on staging. I verified that other expected features were on staging, so...can you run cronscripts/product-release-finder.py on staging and paste/send the output?
[17:34] <Chex> sinzui: jinx. I just finally verified that staging should be up-to-date within the past 24 hours or less
[17:34] <Chex> sinzui: sure
[17:34] <sinzui> fab
[17:36] <rockstar> abentley, just curious, really.  I figure if we're bringing back prereq branches, it'd be really cool to teach the scanner about pipes soon after.
[17:36] <abentley> rockstar: My plan is to teach pipelines about prereq branches first.
[17:37] <rockstar> abentley, I aliased push to sync-pipeline for this very purpose a few weeks ago.
[17:37] <rockstar> abentley, wait, that confuses me.  Pipelines knows which branch came before.
[17:37] <abentley> Right, but right now, they can't propose a branch for merging.
[17:38] <rockstar> abentley, ah, okay.  Yeah, we've talked about that.
[17:38] <jml> leonardr, is the patch you just posted something of a pre-cursor to a trusted gtk workflow?
[17:38] <abentley> So first pipelines is getting launchpad support.  Launchpad might get pipelines support later.
[17:39] <leonardr> jml: yes, i spent this week landing the branch i mentioned to you a while ago
[17:39] <jml> leonardr, cool.
[17:39] <leonardr> i am supposed to talk to rickspencer3 about porting his gtk workflow to this engine but i can't find him. maybe he took the day off now that karmic is released
[17:39] <rockstar> abentley, okay.  I've wanted to do something to the codehosting part of code, and mwhudson fixed the bug I was thinking I'd do, so I thought maybe I'd teach the scanner about pipelines.
[17:39] <rockstar> abentley, just a thought in passing more than anything though.
[17:41] <jml> leonardr, he's travelling back home
[17:41] <leonardr> ah
[17:41] <leonardr> i guess i'll talk to him on monday then
[17:41] <abentley> rockstar: Well, the hardest part is getting a database patch through review.  After that, we can implement direct support for next_branch and prev_branch, or we can add the pipelines plugin to the codebase.
[17:41] <jml> leonardr, trusted client for gtk would be very exciting.
[17:48] <Chex> sinzui: ok, the script stopped output about 15 mins ago, should I kill it?
[17:48] <sinzui> know. I think this can take some time since I expect it to be finding a lot of new downloads
[17:49] <sinzui> s/know/no/
[17:49] <sinzui> Chex: is it stuck on a specific url?
[17:51] <Chex> sinzui: yes : 2009-10-30 17:39:03 INFO    Walking http://ftp.drupal.org
[17:51] <Chex> 2009-10-30 17:39:03 INFO    Listing /files/projects/
[17:52] <sinzui> that is big
[17:53] <sinzui> Chex: Let this run. if this has not moved on in 30 minutes, I think we should kill it and restart
[18:02] <intellectronica> have a lovely weekend and a great week four, everyone. see you in texas
[18:04] <Chex> sinzui: oki doki.. still sitting there as of now.
[18:04] <sinzui> :/
[18:07] <mrevell> Night all. have great weekends!
[18:16] <danilos> salgado, hi, do you know how closely are launchpad_auth_master and launchpad_main_master synced? are they the same DB or not?
[18:17] <salgado> danilos, don't know
[18:17] <danilos> salgado, but just to confirm, user/preferredemail should always be not None when accessed from code, right?
[18:18] <salgado> if you mean LaunchBag.user, then yes
[18:54] <flacoste> man, this django test runner sucks
[19:14] <flacoste> gary_poster, barry: oopstools is testing a script using sys.executable
[19:14] <flacoste> i'm buildoutifying the package, so that doesn't work
[19:14] <flacoste> what is the best thing to do here
[19:14] <flacoste> test through bin/the_buildoutified_script
[19:15] <flacoste> or through bin/py
[19:15] <flacoste> and what is the best way to get the path to bin/... from the test?
[19:16] <barry> flacoste: bin/py bin/the_script probably.  iirc, we do something similar for mailman.  to get to bin i think we os.path.dirname from canonical.__file__
[19:16] <gary_poster> flacoste: I prefer bin/the_buildoutified_script in general.  relying on bin/py is a bit of a hack in my mind, TBH.  It was convenient for us, but from scratch, it it is easy enough, I'd do the script.
[19:16] <flacoste> gary_poster: i agree and that's what i started aiming for
[19:17] <flacoste> now, what is the best way to get the path to bin?
[19:17] <flacoste> should I assume tests are run from the buildout top-level directory
[19:17] <flacoste> ?
[19:17] <barry> gary_poster: did we use bin/py somescript because we would have had to hack mailman?
[19:17] <flacoste> or should I use ../../../ from my test directory using the dirname(__file__) trick?
[19:18] <barry> we really should have a utility that gives us the root of our tree, from which we can easily calculate bin or whatever
[19:18] <gary_poster> flacoste: If you are working with something that has access to buildout variables, then you can use things like ${buildout:bin-directory} (IIRC; I would look for variables on buildout PyPI page)
[19:18] <flacoste> gary_poster: that's just a regular doctest, so I don't think that's the case
[19:19] <flacoste> unless we put those into a module
[19:19] <gary_poster> flacoste: the z3c.recipe.filetemplate will let you do that.  Alternately, if you are doing a script, you can have code inserted (see how we do it in launchpad's buildout.cfg)
[19:19] <flacoste> this is a django app
[19:19] <flacoste> so it needs a settings file
[19:20] <flacoste> which can contain a couple of global stuff
[19:20] <flacoste> i think i'm going to generate that file using z3c.recipe.filetemplate
[19:20] <gary_poster> you could generate that, sure.  I was talking about this: http://pypi.python.org/pypi/zc.recipe.egg#specifying-initialialization-code-and-arguments
[19:20] <flacoste> and put a couple of well-known directory there
[19:20] <gary_poster> that would work too, yeah
[19:20] <flacoste> well, not really
[19:20] <flacoste> because what i want is to find the bin path from the script
[19:20] <flacoste> err, the test
[19:21] <gary_poster> well, you could stuff info in someplace, like environ.
[19:21] <flacoste> ah, you mean in the test wrapper for example
[19:21] <flacoste> but that one is generated through djangorecipe
[19:21] <flacoste> and it's a crappy test runner wrapper anyway
[19:22] <gary_poster> :-) ok
[19:22] <gary_poster> barry: "did we use bin/py somescript because we would have had to hack mailman?" yes, and because there was already precedent
[19:23] <barry> gary_poster: cool
[19:24] <flacoste> man, djangorecipe, what a "!&/)!*"
[19:24] <flacoste> it doesn't put Django into the eggs
[19:24] <flacoste> and it doesn't install django as an egg, but into build/parts
[19:25] <flacoste> which means that scripts generated don't have it in their path
[19:25] <flacoste> pff
[19:25] <flacoste> extra_path to the rescue...
[19:34] <flacoste> gary_poster: any idea why extra-paths isn't adding stuff to the generated script?
[19:34] <flacoste> gary_poster: i think i know why
[19:36] <gary_poster> flacoste: no.  It should.  (though, btw, on a a probably unreleated topic, I suggest that you do one of these three: (1) use a clean Python, (2) use a virtualenv clean Python (--no-site-packages), or (3) somehow use my zc.buildout and zc.recipe.egg and z3c.recipe.filetemplate internal releases.
[19:36] <gary_poster> )
[19:37] <flacoste> gary_poster: it was a confusion on my part
[19:37] <flacoste> gary_poster: i had commented out the scripts stanza from the buildout parts
[19:37] <flacoste> gary_poster: but the script was still generated through the interpreter section
[19:37] <gary_poster> oic
[19:37] <flacoste> gary_poster: which didn't have the extra-paths config
[19:37] <gary_poster> you can combine the two fwiw
[19:37] <flacoste> it's weird though that the interpreter section generates script
[19:37] <flacoste> yeah
[19:37] <flacoste> exactly
[19:41] <flacoste> yeah! all tests are now passing!
[19:41] <gary_poster> awesome :-)
[19:57] <barry> sinzui: ping
[20:06] <sinzui>  hi barry
[20:07] <barry> sinzui: hi.  open up lib/canonical/launchpad/icing/style-3.0.css and search for registered
[20:08] <sinzui> ouch
[20:08] <barry> :)
[20:09] <sinzui> so we still have a problem in that italics is wrong
[20:09] <barry> sinzui: maybe it should have been "registering"?
[20:09] <sinzui> oh, I see, it is correct when in an li
[20:09] <sinzui> so the portlet is not putting the person's join time in an li
[20:10] <barry> sinzui: maybe.  but if you look at https://launchpad.dev/firefox you'll see that the registration date is class="registering"
[20:11] <barry> should would be nice if we had some more comments in our css :/
[20:11] <sinzui> We certainly do no want to float the secondary information to the link
[20:11] <sinzui> no, it would be nice if we took the time to rename our classes when we broaden their use
[20:11] <sinzui> comments are needed when you write too many specific rules
[20:11] <barry> well, perhaps, but the color and font-size seem more in line with registered
[20:12] <sinzui> I want the text to look like other portlets. We have a markup/style problem because when that is next to other portlets it is clearly wrong. There is nothing special about it
[20:13] <barry> the problem is that you really have no idea what ".registered" is used for, so you can't safely change it, so that leads to more fragmentation as you add more classes
[20:13] <sinzui> barry: look at https://edge.launchpad.net/launchpad-registry
[20:14] <sinzui> The grey normal text is what the user expects to see, he does not care how we do it. So when I saw italics, I knew something was wrong, my guess was certainly wrong about the cause
[20:14] <sinzui> barry: can you spot the defect in this page by BTW?
[20:15] <barry> sinzui: so, i agree that the italics is wrong, but /we/ definitely care how we fix it.  not much to say at the end of the cycle, but style-3.0.css is going to end up a mess this way
[20:16] <sinzui> We can start cleaning it up by removing the old stylesheet rules
[20:16] <barry> i don't understand why we have .registered and li . registered
[20:17] <sinzui> one is italics and the other is not. The italics rule is from the contracted design. kiko later wanted italics removed, this one was not
[20:18] <sinzui> .registering first used under the object's title. The design changed a lot in the 3.0 milestone.
[20:18] <barry> sinzui: so, why wasn't font-style: italic; removed from .registered?
[20:18] <kiko> ITALICS!!!
[20:19] <sinzui> barry: dude get a grip. do I have to make you read the 3.0, and the post cleanup list?
[20:19] <sinzui> barry: I'll be happy if you can triple your landings each month, but I do not want to break anyones spirt
[20:20] <barry> sinzui: i am chilled out!  i'm trying to make sense of stuff in our tree that makes no sense
[20:20] <sinzui> barry: label it tech-debt so that it makes the list of things we schedule work on.
[20:21] <sinzui> except that we are not really scheduling tech-debt
[20:21] <barry> sinzui: but we /are/ cleaning up ui, right?
[20:21] <sinzui> yes, after oops
[20:23] <sinzui> barry: our team closed about 20 ui issues this release, but we are a smaller team now, we still own 1/3 of all templates, and we are still expected to own blueprint and answers templates. The latter two completely missed their milestones
[20:23] <barry> sinzui: cool.  this is definitely ui uncleanliness, but we need to avoid chaos too, or it's hopeless ;)
[20:23] <sinzui> barry: We will never look as good as the other teams given that we cannot put enough people onto the issues
[20:40] <flacoste> gary_poster: is there a list of buildout variables?
[20:43] <gary_poster> flacoste: yes, in docs plus there is a command to see the defaults.  Looking...
[20:43] <flacoste> gary_poster: i don't find it from the pypi page
[20:45] <gary_poster> flacoste: not sure what you are looking for, but bin/buildout annotate will list default values
[20:45] <flacoste> ok, thanks
[20:45] <gary_poster> flacoste: also, http://pypi.python.org/pypi/zc.buildout#predefined-buildout-options
[20:48] <Chex> sinzui: just a update, your script is still running, and creating output now
[20:49] <sinzui> Chex: fab. I fixed a loop issue that prevented the script for download all the tarballs. I have a list of things I can check tonight if the script does not complete soon
[20:50] <Chex> sinzui: ok, sounds good, just because us losas will be rolling up the sidewalk soon, wanted to see if you needed us to check status
[21:25] <wgrant> How do week 4 landings work? I'll probably be wanting to land some new Soyuz enum values to make something easier to CP during 3.1.12 if Debian forces us to.
[21:27] <lifeless> get RC approval
[21:27] <lifeless> AIUI
[21:48] <wgrant> sinzui: Can bug #464014 no make 3.1.10?
[21:48] <mup> Bug #464014: DistributionSourcePackageView.active_series sorts versions as strings <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/464014>
[21:49] <wgrant> sinzui: It is going to become a problem very soon, and seems like an easy fix.
[21:49] <sinzui> wgrant: no, we are lock down in a few minutes, the EC2 run time is 4 hours so once we crossed the threshold I push all the bugs back
[21:50] <sinzui> wgrant: I am working in DSP's now and I feel the pain
[21:50] <sinzui> Maybe I can convince someone that this is an RC able issue
[21:51] <sinzui> wgrant: we will work have a branch ready next week, but I do not want to promise that it will be released
[21:51] <wgrant> sinzui: cjwatson filed a dupe overnight.
[21:51] <wgrant> Thanks.
[21:51] <sinzui> wgrant: I think the fix is to use sorted_dotted_numbers
[21:52] <sinzui> I assumed that was what we used to show the DSP
[21:52] <wgrant> sinzui: Isn't the DS version a debversion?
[21:53] <sinzui> either will do. We have be using the other because it handles cases of letters
[21:53] <sinzui> not that LTS will ever appear in a version
[21:53]  * wgrant checks how Distribution:+index does it.
[21:54] <wgrant>         return sorted(ret, key=lambda a: Version(a.version), reverse=True)
[21:54] <sinzui> Doom to fail
[21:54] <wgrant> Why?
[21:54] <sinzui> Doomed to fail
[21:55] <sinzui> version is not a number
[21:56] <wgrant> How does that matter?
[21:56] <wgrant> debversion uses Debian ordering rules, which care about a lot more than just numbers.
[21:56] <sinzui> sort is follows string rules, so 10 and 1 are much different
[21:57] <sinzui> right, and debversion has a lot a tested/proven behaviour
[21:57] <wgrant> Why would sort be using string rules on a Version object with a __cmp__?
[21:58] <sinzui> The release/version is in point of fact a debversion, though the DB thinks it is something more loosely defined
[21:59] <sinzui> Version is not an object
[21:59] <wgrant> It is.
[21:59] <wgrant> lp.archivepublisher.debversion.Version
[22:00] <sinzui> I am mistaken then. In know the DB does not know that.
[22:00] <wgrant> Right. The DB just enforces sane_version, which is something different. I wonder if the interface enforces debversion.
[22:01] <sinzui> The IField does
[22:01] <wgrant> Great.
[22:01] <wgrant> Does Registry have sufficient engineering time this cycle to make that trivial change with a test?
[22:02] <sinzui> I think so
[23:36] <Ursinha> ahem.
[23:36] <Ursinha> I hate writing tests.