[00:32]  * mwhudson lunches
[01:12] <wgrant> poolie: Is it really that odd to support only OpenID? Most Canonical web services exclusively use Ubuntu SSO.
[01:12] <wgrant> There's little point have a webapp-specific username and password.
[01:12] <poolie> i meant among other web apps generally
[01:13] <thumper> mwhudson: do you know anything about ampoule?
[01:13] <poolie> they seem to at least present the impression of letting you enter the username/password directly
[01:13] <poolie> through a web page or over a machine interface
[01:13] <poolie> even if in the backend it's going to a generalized db
[01:13] <poolie> don't you think so?
[01:14] <wgrant> Right -- but what's the point?
[01:15] <wgrant> Er, wait, are you talking about webapps in general, or Canonical webapps?
[01:15] <poolie> generally
[01:15] <wgrant> Ah.
[01:16] <wgrant> Well, what benefit does this provide?
[01:17] <wgrant> In this case there is a default OpenID provider that makes a little bit of sense but not really, so it makes sense in the minds of people who want to associate Launchpad even further with Ubuntu to delegate all authentication to that.
[01:17] <wgrant> Hopefully LP will soon be able to auth against any provider, which might make it less completely unacceptable to most distro-agnostic upstreams.
[01:17] <wgrant> Forcing upstream projects through an Ubuntu-branded page is *not* going to make people happy.
[01:18] <wgrant> But I think dropping the internal authentication is a good move.
[01:18] <poolie> (phone)
[01:18] <poolie> i think it's useful to be able to do "curl https://user:pass@launchpad.net/something"
[01:21] <wgrant> I haven't had to do that in ages, thanks to the API.
[01:22] <poolie> or similarly for the api
[01:22] <poolie> which is where we started
[01:30] <wgrant> The only supported auth mechanism for API requests is OAuth. The workflow for getting an OAuth token can be easily streamlined.
[01:30]  * thumper stabby
[01:30] <thumper> :(
[01:39] <mwhudson> thumper: only in general terms
[01:39] <thumper> mwhudson: I'm stuck and would like help
[01:39] <mwhudson> thumper: ok
[01:39] <mwhudson> thumper: skype?
[01:39] <thumper> please
[01:40] <mwhudson> oh right, it's not running...
[01:45] <thumper> lp:~thumper/launchpad/all-code-review-email-using-jobs
[01:51] <NCommander> In general, how bad of an idea is it to count the number of rows in SRP?
[01:51]  * NCommander is working on the importer now that I have some time
[02:02] <NCommander> My postgresql is rusty, how do you select columns where an integer column is unset (but not null, the parser doesn't seem to like '')
[02:02] <NCommander> bah,nm
[02:03] <lifeless> NCommander: unset *is* NULL
[02:03] <lifeless> NCommander: '' is not NULL
[02:04] <wgrant> NCommander: SRP? You mean SPR?
[02:07] <NCommander> wgrant: er, yeah
[02:07] <NCommander> lifeless: yeah, I had a bad flashback to mysql, and forgot that postgresql doesn't suffer that much braindamage
[02:08] <wgrant> NCommander: Why do you want to?
[02:08] <NCommander> wgrant: to give a total and an overall progress (this is probably going to take days run), but I also found count(*) does a sequential scan thus, may not be the best to run on such a large table :-)
[02:09] <wgrant> Possibly. Hard to say.
[02:09] <wgrant> Just do it, I think. If it becomes a problem, it can be fixed.
[02:09] <wgrant> Premature optimisation, and all that.
[02:12] <NCommander> wgrant: fair enough, I'm thinking I can't do this as one giant transaction, but break it into batches
[02:14] <wgrant> NCommander: stub would come and strangle you if you did it in one transaction.
[02:15] <NCommander> wgrant: yes, well :-), I dunno how much ot run in a batch
[02:16] <wgrant> There is DBLoopTuner, but I don't think that handles committing for you.
[02:16] <NCommander> 21:15:08 < NCommander> wgrant: yes, well :-), I dunno how much ot run in a batch
[02:16] <NCommander> 21:15:42 < wgrant> There is DBLoopTuner, but I don't think that handles committing for you.
[02:16] <NCommander> argh
[02:16] <NCommander> wgrant: what's DBLoopTuner
[02:16] <wgrant> It handles batching and automatically tunes the batch size to meet a target time.
[02:17] <wgrant> Not sure how applicable it would be to this case, though.
[02:20] <NCommander> wgrant: ah
[02:21] <thumper> mwhudson: skype fail
[02:23] <mwhudson> thumper: wifi fail
[02:29] <thumper> http://pastebin.ubuntu.com/406280/
[02:31] <mwhudson> anyone know how to debug postgres deadlocks?
[02:33] <mwhudson> using pg_locks and all that
[02:54] <lifeless> mwhudson: I've done so in the past
[02:54] <lifeless> mwhudson: still need help ?
[02:54] <mwhudson> lifeless: nah, we found it
[02:54] <mwhudson> ta though
[03:25] <NCommander> Stupid question, but is there a good example on how to retrieve a file via librarian?
[03:27]  * NCommander is trying to figure out how to sanely download all the bits of a source package giving a SPR record
[03:30] <mwhudson> NCommander: via the api or ... ?
[03:32] <NCommander> mwhudson: I'm writing a script to handle migration for raw_source_changelog but my inexperience with LP's internal APIs are making it difficult, i.e., how to get a file from librarian, or getting all the bits of a source package, etc.
[03:37] <mwhudson> NCommander: getting a file from the librarian is quite easy
[03:37] <mwhudson> NCommander: it's just librarianfilealias.open()
[03:37] <mwhudson> source packages i'm less sure of
[03:38] <NCommander> mwhudson: well, I already have a function that spits out all the id numbers and filenames of the source package :-)
[03:39] <NCommander> mwhudson: I'm not sure I can determine that given a specific LFA though if its in the restricted librarian or in the primary one
[03:39] <mwhudson> NCommander: i think lfa.open() dtrt
[03:40] <NCommander> dtrt?
[03:44] <mwhudson> NCommander: does the right thing
[03:44] <NCommander> mwhudson: ahhhhhh
[04:21]  * thumper afk for urgent shopping for dinner
[04:26] <wgrant> NCommander: LFA.restricted should tell you whether it's restricted.
[04:26] <NCommander> wgrant: can I just lfa.open() or do I have to do something special if its restricted?
[04:26] <wgrant> NCommander: LFA.open() should work fine.
[04:27] <NCommander> wgrant: perfect!
[04:30] <poolie> is hackberry the staging db or the real one?
[04:32] <mwhudson> poolie: it's a slave not one of the masters
[04:32] <poolie> but a slave of the production db?
[04:32] <poolie> iow scripts running there see up-to-date data?
[04:32] <mwhudson> poolie: looks like a slave of production, yeah
[04:39] <poolie> thanks
[04:40] <spm> poolie: https://devpad.canonical.com/~spm/launchpad-sec-levels.png hackberry is a slave; is < 5 minutes behind in replication or I get sms'd.
[04:41] <poolie> nice
[04:44] <spm> hrm. dated too. missing soybean for 1.
[04:44] <spm> bleh. and pear.
[06:34]  * thumper back later to finish submitting proposals
[07:27] <wgrant> henninge: Morning.
[07:27] <henninge> Hi wgrant! ;)
[07:28] <wgrant> henninge: With https://code.edge.launchpad.net/~wgrant/launchpad/get-translations-jobs-working, translation template jobs work completely.
[07:28] <wgrant> Just needed a few tweaks in untestable code.
[07:28] <henninge> wgrant: Great to hear!
[07:28] <henninge> let me look at it
[07:28] <stub> Is there a PPA with basic Python 2.4 for Lucid? Lost 2.4 during the upgrade.
[07:29] <StevenK> stub: You should be able to drag it in from Karmic
[07:29] <wgrant> henninge: It has a few prereqs, one of which been rejected, so it will have to wait for the data model rework.
[07:29] <wgrant> stub: Why would you want 2.4?
[07:29] <stub> Because I build pytz for Python 2.3+
[07:30] <wgrant> Ah.
[07:30] <wgrant> henninge: But it was encouraging to see that it actually pretty much works.
[07:30] <wgrant> And doesn't break the UI any more.
[07:31] <wgrant> (and also gave me a crash course in Rosetta, which I'd not used before!)
[07:31] <henninge> wgrant: yes, that is an important step forward.
[07:31] <henninge> ;-)
[07:31] <henninge> welcome!
[07:33] <wgrant> henninge: What's going to happen during an update when new POs are scraped from the branch and uploaded before the new POT finishes building?
[07:34] <henninge> wgrant: POs without a template will not be imported until the template has been imported.
[07:34] <wgrant> henninge: Things aren't going to break strangely if POs with new strings are uploaded before the POT with those strings, though?
[07:39] <henninge> wgrant: let me look at this but I think not
[07:39] <adeuring> good morning
[07:51] <noodles775> Hallo.
[07:51] <henninge> wgrant: yes, all messages are stored in the database, even those that don't have a matching template entry (yet).
[07:51] <wgrant> henninge: Ah, great.
[07:51] <henninge> wgrant: they are marked as obsolete.
[07:51] <henninge> but will be un-obsolleted once the template comes in.
[07:51] <henninge> noodles775: moin!
[07:52] <noodles775> Hi henninge
[07:52] <wgrant> henninge: Just thought it might be a bit of a new situation, since existing bzr imports are synchronous.
[07:53] <henninge> wgrant: well, we have always had manual uploads and they would come in any order the uploader chooses .... ;)
[07:54] <wgrant> henninge: True.
[08:43]  * wgrant looks for a reviewer for the RC candidate https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288
[08:53]  * thumper EODs
[09:02] <mrevell> Morning
[09:08]  * wgrant ponders removing ViewByLoggedInUser (the default IAuthorization adapter) and seeing what breaks.
[09:09] <wgrant> It is dangerous.
[09:10] <bigjools> g'day
[09:10] <wgrant> Morning bigjools.
[09:11] <bigjools> what's broken today?
[09:12] <wgrant> SPRB permissions are bogus.
[09:12] <wgrant> But not an actual problem yet, of course.
[09:47] <jml> gary_poster,
[09:47] <jml> good morning
[09:50] <jml> wgrant, there's a default adapter? I think I knew that.
[09:50] <jml> wgrant, I'm surprised the default is something like that though.
[09:51] <wgrant> jml: Yes :(
[09:51] <wgrant> It is perhaps the most silly default possible.
[09:51] <wgrant> Except perhaps for allowing unauthenticated users and forbidding authenticated ones.
[09:59] <wgrant> bigjools: Thanks. I've filed a bug and added it to the XXX.
[10:00] <bigjools> ta
[10:18] <bigjools> wgrant: mind if I mark bug 549340 as invalid?
[10:18] <mup> Bug #549340: BuildQueue.destroySelf erroneously assumes that all jobs are Storm objects <buildfarm> <Soyuz:In Progress by wgrant> <https://launchpad.net/bugs/549340>
[10:18] <wgrant> bigjools: Go ahead.
[10:19] <bigjools> wgrant: thanks
[10:20] <wgrant> Although I still believe that it's an interface violation, we'll see what happens once the model changes are shaken out.
[10:21] <bigjools> yep
[10:25] <bigjools> stub: dogfood has got a load of pg backends running that we can't cancel (mainly connecting to sso_main and launchpad_auth), what's the best thing to do?
[10:28] <stub> bounce postgres probably.
[10:28] <stub> pg_ctlcluster -force 8.3 main restart
[10:29] <stub> Need a losa I guess
[10:30] <mthaddon> actually, that'd need a GSA, losas don't have perms on dogfood (because we don't manage it)
[10:33] <bigjools> stub: also, lazr.config.interfaces.ConfigErrors: ConfigErrors: database does not have a main_slave key.
[10:33] <bigjools> database does not have a main_master key.
[10:33] <bigjools> wtf?
[10:33] <stub> bigjools: Perhaps you should request access as the postgres user? You can escalate your privs if you try hard anyway so it doesn't make much sense from a security point of view.
[10:33] <bigjools> yeah sounds sane
[10:33] <bigjools> well - I can do some stuff as postgres already
[10:34] <stub> bigjools: It changed to rw_main_master I believe for read only mode stuff.
[10:34] <bigjools> stub: does this mean we need a database refresh or what?
[10:34] <stub> Its a config file change. I don't think you need to rebuild your database for that.
[10:35] <bigjools> thought we'd changed that, hmm
[10:38] <bigjools> yes we had, it got reverted
[10:45] <bigjools> stub: there was a bin/run knocking around for some reason, killing that removed all the backends
[11:03] <deryck> Morning, all.
[11:10] <mwhudson> deryck: gosh, if you're online it must be time to go to bed
[11:11] <deryck> mwhudson, heh.  yup.  I have some more western lying Europeans that serve as that marker for me. :-)
[11:31] <allenap> soyuz: Are you aware of a failure in buildd-slave.txt <http://paste.ubuntu.com/406449/>? About 20 minutes ago I also saw it break with a "Connection reset by peer" instead of "Connection refused", but I can't seem to replicate that now.
[11:32] <wgrant> It's started failing spuriously in various ways lately :(
[11:34] <allenap> wgrant: Ah, well, at least you know, and it's not something I've broken for you.
[12:51] <wgrant> bigjools: I don't think it's GPL-safe to remove sources that are still referenced by binaries.
[12:52] <wgrant> As for the stay of execution... I'm not sure of the purpose of that, unless it's to leave old indices working for a while.
[12:58] <wgrant> GPL2 is rather handwavy about it, but GPL3 is much more specific.
[12:58] <bigjools> wgrant: I wasn't suggesting to do that
[12:58] <bigjools> I'm talking about getting rid of "stay of execution"
[12:59] <wgrant> It is handy if you don't want to apt-get update every publishing cycle.
[12:59] <bigjools> I don't think we remove sources referenced by binaries right now do we?
[13:00] <bigjools> wgrant: how does it make any difference to apt-get?
[13:00] <bigjools> the index changes, that's what apt-cares about
[13:00] <bigjools> s/-/ /
[13:01] <wgrant> bigjools: We deindex them, but they are not removed from disk.
[13:01] <bigjools> yes, and how does that affect apt-get if we remove them from disk at the same time?
[13:02] <wgrant> bigjools: If I have a machine that updates its indices once a day (the default) and a package gets superseded some time between updates, I will get a 404 and installations and upgrades will fail. That is ugly.
[13:03] <bigjools> I'd say that is desirable behaviour
[13:03] <bigjools> your index is out of date
[13:03] <wgrant> We have that behaviour for deletions, when removal is obviously desired.
[13:05] <wgrant> But 404s look bad. And they will happen in released versions. To lots of users.
[13:06] <wgrant> The behaviour is different (the stay of execution is set at 24 hours) for PPAs; maybe the PPA spec has some rationale?
[13:07] <bigjools> hmmm
[13:07] <bigjools> oh fuck sake, email crash, I hate that
[13:08] <bigjools> wgrant: I guess we have to suck it up then, updating indices hours before downloading the files is crack IMO but there you go :/
[13:09] <wgrant> bigjools: Indices are huge.
[13:09] <bigjools> unfortunately so
[13:13] <wgrant> Ideally we'd have something like (or better than) pdiffs: publishing could take less than a second rather than a couple of minutes, and updating before downloading would be easy.
[13:14] <StevenK> But pdiffs just sucks
[13:14] <bigjools> StevenK: what's better?
[13:15] <wgrant> pdiffs suck, yes.
[13:15] <wgrant> It would be much better to just allow additional files which provide additional entries.
[13:15] <wgrant> Much quicker to generate, and probably to apply too.
[13:15] <StevenK> bigjools: When you have a large delta, just redownloading the file. If the delta is small, rsync?
[13:16] <StevenK> But that is hard to determine, and most of the smarts are on the client and it means the server must provide rsync, so that sucks more.
[13:16] <StevenK> I'd rather we didn't provide pdiffs, they annoy me.
[13:16] <bigjools> it would be nice to shake this all up a bit
[13:17]  * jml shuts down email
[13:22] <wgrant> bigjools: What's going to happen with the apt-ftparchive test failures?
[13:22] <wgrant> We are getting close to Lucid.
[13:22] <ricotz> hello, how often is there synchronization between different translation templates of a project? So how long does it take that a change is visible in another template?
[13:22] <bigjools> wgrant: we either get them fixed, or block the lucid upgrade in the DC
[13:22] <bigjools> I prefer the former of course :)
[13:23] <wgrant> bigjools: Or we could accept them as better behaviour, of course...
[13:23] <jml> my dns is down
[13:24] <bigjools> wgrant: fixing can include that definition, yes
[13:24] <wgrant> True.
[13:24] <bigjools> is there a bug filed?
[13:25] <bigjools> I need to get it scheduled for the next cycle so we don't miss it
[13:25] <wgrant> Bug #526826
[13:25] <mup> Bug #526826: test_ftparchive failing on Lucid <soyuz-publish> <tech-debt> <Soyuz:Triaged> <https://launchpad.net/bugs/526826>
[13:25] <bigjools> fanks
[13:25] <wgrant> Although it's also affecting soyuz-upload.txt now that I've reenabled it.
[13:26] <bigjools> bleh
[13:26]  * jml does the modprobe dance, maybe that'll help.
[13:26] <jml> it does.
[13:29] <jml> bigjools, I'm going to get back on that poppy stuff now
[13:29] <bigjools> \o/
[13:29] <bigjools> people will send you chocolate
[13:30] <wgrant> As in SFTP poppy?
[13:30] <jml> wgrant, yeah.
[13:30] <jml> wgrant, although this is more "get the juicy non-codehosting ssh bits out of codehosting so I can think straight about sftp poppy"
[13:30] <wgrant> jml: Ah.
[13:30] <noodles775> jml: did you see https://dev.launchpad.net/LEP/GeneralBuildHistories ? Later, when you want a break from poppy, can you take a look?
[13:31] <jml> noodles775, no, I didn't.
[13:31] <jml> noodles775, I'll check it out later.
[13:32] <noodles775> jml: yeah, do some coding for a change :D
[13:35] <jml> I wonder when I'll be able to land the zope.testing change.
[13:46] <noodles775> wgrant: /w 5
[13:46] <noodles775> woops
[13:48] <jml> I really need to configure my shell to make a noise when long-running commands complete
[13:48] <jml> I wonder if that's at all possible
[13:50] <wgrant> jml: Some terminal emulators have a "wait for silence" option.
[13:50] <wgrant> GNOME has probably removed it, though.
[13:50] <wgrant> Maybe I'm think of Konsole.
[13:51] <bigjools> Konsole has "monitor for silence"
[13:51] <bigjools> it also has "monitor for activity"
[13:51] <wgrant> Yeah, that's the one.
[13:51] <bigjools> isn't KDE cool :)
[13:51] <jml> terminator doesn't :)
[13:55] <wgrant> Is it just me, or does make take an awful long time these days?
[13:56] <bigjools> it's not just you
[13:56] <bigjools> see all the junk it keeps doing over and over for each branch, when it could do it once in a common area
[13:56] <wgrant> With all this mailman building and WADL generation and apidoc compilation and JS combination.
[13:57] <wgrant> Some of which is done on every single build; not just in the 5-minute initial tree build.
[13:58] <bigjools> and that
[13:59] <maxb> It feels like all the JS stuff is what's got slower recently
[13:59] <maxb> Maybe we should have a test which asserts on "make; time make" :-)
[14:00] <wgrant> See, I just ran 'time make' in devel.
[14:00] <wgrant> It spends a few seconds bootstrapping for no good reason.
[14:00] <wgrant> Then rebuilds mailma.
[14:00] <wgrant> The jsbuild/jssize/combine-css take a while.
[14:00] <wgrant> But it seems that rebuilds only take around 45 seconds.
[14:00] <wgrant> Ah, no apidoc in that run.
[14:01] <jml> 45s for a rebuild with no changes?
[14:01] <bigjools> the make target dependencies suck donkey balls
[14:02] <wgrant> jml: That was with a cold cache. 20s with it hot.
[14:02] <jml> wgrant, that's still quite a long time spent achieving nothing.
[14:02] <wgrant> Yes.
[14:03] <wgrant> Now let's see if I can get it to trigger an apidoc build...
[14:03] <wgrant> Hm, maybe it does only do that on clean builds.
[14:04] <bigjools> yes the dependency is set up right for that
[14:05] <jml> fixing the make stuff wouldn't be too hard, I bet.
[14:05] <jml> I mean, the full on right thing to do is make a list of standard bits of a developer's cycle and optimise the crap out of all of them
[14:06] <jml> but just getting 'make' to do less for the 90% case and then putting some strongly-worded documentation to stop it from creeping again wouldn't be that hard.
[14:08]  * jml accidentally pissed some time away apt-get upgrading when apt-get install python-apt was all that was necessary
[14:09] <bigjools> jml: + [a lot]
[14:09] <bigjools> can you make it happen?
[14:10] <jml> bigjools, I'm not going to make the change myself, most likely.
[14:11] <bigjools> jml: well that's not quite what I meant :)
[14:11] <jml> bigjools, and I've already been trying really really hard to let everyone know that I want them to stop what they are doing and make development faster
[14:12] <jml> bigjools, but maybe I'm trying in the wrong way, or something.
[14:12] <wgrant> jml: Bonus points if you convince people to make Launchpad faster, too.
[14:12] <wgrant> real	4m38.942s
[14:12] <wgrant> Awesome. That is a great way to encourage branching.
[14:12] <jml> wgrant, yeah, that's a separate problem that I'm tackling.
[14:13] <jml> wgrant, or rather, gary_poster's team are already making LP faster.
[14:13] <bigjools> jml: at our upcoming Epic, I want us to schedule time to make development better.  Stuff like this.
[14:13] <wgrant> jml: I made the mistake of using Github for a while earlier today.
[14:13] <bigjools> and I think you expressed that is a good idea in the past
[14:14] <wgrant> it is so fast, and the code browser is part of the application and doesn't time out constantly.
[14:14] <jml> bigjools, I think that would be a good idea. but I don't really see why we need to wait until July.
[14:17] <bigjools> jml: we don't, but there's nothing like a concerted group effort to effect real change
[14:18] <jml> bigjools, as long as it's organized to be _doing_ and not talking.
[14:19] <jml> bigjools, I also advocated that we have someone work full time on making development faster. The build engineer role hasn't been as successful as I hoped.
[14:19] <kfogel> bigjools: should bug 551579 be moved to launchpad-buildd or to soyuz?
[14:20] <mup> Bug #551579: Unable to build a PPA package with locked down permissions <Launchpad itself:New> <https://launchpad.net/bugs/551579>
[14:20] <bigjools> kfogel: let me lookl
[14:20] <bigjools> jml: yes - I think our time is being squeezed too much between different things
[14:20] <wgrant> kfogel: It's a bug in the package.
[14:20] <wgrant> But otherwise launchpad-buildd.
[14:20] <jml> bigjools, the list of developer bugs hasn't really moved much https://bugs.edge.launchpad.net/launchpad-foundations/+bugs?field.tag=build-infrastructure
[14:21] <kfogel> wgrant: oh!  (but thanks, that info is helpful for next time)
[14:21] <wgrant> (it's the same bug that is being discussed in #launchpad at the moment)
[14:21] <wgrant> s/bug/thing/
[14:21] <kfogel> wgrant: actually, it should still be moved to launchpad-buildd then (though I'll wait for bigjools to come back)
[14:21] <bigjools> kfogel, wgrant: hmmm
[14:21] <bigjools> so basically it wants to be run as root
[14:22] <bigjools> I don't like that
[14:22] <kfogel> bigjools: while I care somewhat about the big picture, I care mainly about getting it out of the "Launchpad Itself" queue (I'm CHR today) :-).
[14:22] <StevenK> I think it's a package bug
[14:22] <wgrant> No, it's a bug in the package that it breaks fakeroot.
[14:22] <bigjools> me too
[14:22] <bigjools> kfogel: it's invalid
[14:24] <kfogel> bigjools: *nod*  Want me to mark it as such, and quote this IRC conversation for why?
[14:24] <bigjools> kfogel: yep
[14:24] <bigjools> thanks
[14:25] <jml> bigjools, how does "too many different things" apply to the build engineer role?
[14:26] <bigjools> jml: I suspect that role has not been given the attention it deserves
[14:27] <jml> bigjools, yeah, I'd agree with that.
[14:29] <bigjools> jml: what I mean is, the pressure to get the team work done has probably usurped it
[14:31] <jml> bigjools, ahh, I see. Do you have any ideas as to what we can do about that?
[14:31] <bigjools> jml: schedule less work? :)
[14:32] <jml> bigjools, you mean, like we did already?
[14:32] <bigjools> I don;t see that personally
[14:32] <jml> bigjools, well, I don't know what scheduling less would look like in that case
[14:32] <jml> we went from each team having a list of 10+ things to do for 3.0
[14:33] <jml> to having less than ten things in total
[14:33] <bigjools> jml: well I'm still guessing here - it would be better to talk to the build engineers
[14:35] <henninge> ricotz: did you get an answer to your question?
[14:35] <jml> bigjools, that's certainly a good thing to do :)
[14:35]  * henninge is too lazy to read all the backscroll ... ;-)
[14:36]  * jml goes off to perform the "is toast food" experiment
[14:36] <jml> I am highly confident of a successful result.
[14:36] <bigjools> jml: anyway in soyuz world we get a lot of emergencies
[14:36] <bigjools> hence my feeling of lots of work still
[14:37] <jml> fail. cleaner is still occupying all the kitchen
[15:01] <ricotz> henninge, not yet
[15:02] <henninge> ricotz: there is no synchronization between templates within a series, if you are referring to that.
[15:02] <henninge> ricotz: templates of the same *name* in different series of a project will share translations.
[15:02] <henninge> And that instantly, no snychroniation time.
[15:03] <henninge> ricotz: can you point me to where it is you are expecting the synchronisation to happen?
[15:05] <ricotz> henninge, ok, i see it now they are in sync, but the colors arent right
[15:05] <ricotz> https://translations.edge.launchpad.net/docky/trunk/+pots/docky
[15:05] <ricotz> https://translations.edge.launchpad.net/docky/2.0/+pots/docky
[15:06] <ricotz> henninge,  hm, they are not in sync ;-), have a look at Icelandic
[15:07]  * henninge looks
[15:09] <henninge> ricotz: how different (or similar) are the templates, though?
[15:09] <henninge> ricotz: oh, are you just looking at the numbers on the overview page?
[15:10] <henninge> ricotz: they may be outdated.
[15:10] <ricotz> henninge, i am relying on the graphics
[15:10]  * ricotz brb
[15:15] <ricotz> henninge, all strings which are included in series 2.0 are also in series trunk
[15:33]  * jml makes another attempt at toast
[16:03] <henninge> ricotz: comparing the Icelandic files gives this: http://paste.ubuntu.com/406575/
[16:04] <henninge> ricotz: only additions in the trunk file, just like in the template. So the files are in sync.
[16:04] <henninge> ricotz: looks like the PO file statistics are still messed up, sorry about that.
[16:05] <henninge> ricotz: we have the daily script disabled because of performance issues. The weekly script should fix them, hopefully.
[17:11] <kfogel> adeuring: in my branch's Makefile, it still says "PYTHON_VERSION=2.5", but of course Lucid has 2.6.  What's the "clean" way to update that (i.e., I assume editing it directly and having a local mod is not how this is done?)
[17:11] <kfogel> adeuring: https://dev.launchpad.net/Running/Lucid doesn't seem to address this point
[17:11] <adeuring> kfogel: I haven't yet upgraded.
[17:12] <adeuring> last week I was sprinting, and now we are quite closed to the rollout ;)
[17:12] <adeuring> so, no idea...
[17:12] <kfogel> adeuring: np
[17:12] <kfogel> barry: have you upgraded to lucid?  If so, please see my above question to adeuring :-).
[17:13] <kfogel> Oh, maybe answer is (re)install Launchpad PPA.
[17:20] <kfogel> wgrant: ping
[17:53] <kfogel> gary_poster: are you developing on Lucid?  I've run into a small prob.
[17:53] <gary_poster> kfogel: I have various attempts half-made, which effectively means "no".  It's conceivable I can still help.  What's up.
[17:54] <kfogel> gary_poster: my /etc/apt/sources.list has "deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu lucid main", and I have done 'sudo aptitude update'.  Nevertheless, 'sudo aptitude install launchpad-dependencies' just says "no such package".  Yet https://dev.launchpad.net/Running/Lucid implies this is the way I should get Python 2.5 back on my system (Lucid has 2.6) so I can develop Launchpad.
[17:57] <gary_poster> kfogel: I don't think chromium has anything to do with it.  Try
[17:57] <gary_poster> deb http://ppa.launchpad.net/launchpad/ppa/ubuntu lucid main
[17:57] <gary_poster> deb-src http://ppa.launchpad.net/launchpad/ppa/ubuntu lucid main
[17:57] <kfogel> gary_poster: hmm, that may be the wrong ppa
[17:58] <kfogel> gary_poster: thanks, yeah, just got there at the same time I think.
[17:58] <gary_poster> :-)
[18:08] <jml> man I've written some abysmal code in my time
[18:11] <kfogel> jml: so, uh, what prompted you to say that? :-)
[18:11] <jml> kfogel, lib/lp/codehosting/sshserver/accesslog.py
[18:11] <kfogel> jml: (though I'll bet I can win that contest: http://red-bean.com/cvs2cl/cvs2cl.pl)
[18:11]  * kfogel looks
[18:11] <jml> kfogel, that URL says basically everything I need to know.
[18:12] <kfogel> jml: wow, that's a lot of classes
[18:12] <kfogel> :-)
[18:12] <jml> oh right, you are looking at the "old" version
[18:12] <kfogel> jml: (responding to accesslog.py, not cvs2cl.pl, about which your comment is very sensible)
[18:12] <jml> mostly I'm looking at LoggingManager, since I've put all of the other classes in a box
[18:14] <kfogel> jml: hunh.  weird that setUp() isn't __init__(); and something similar with tearDown().  Or is that your point?
[18:15] <jml> kfogel, not specifically, since both setUp and tearDown mutate global state and I hate it when objects do that on construction
[18:15] <kfogel> jml: ah, gotcha
[18:16] <kfogel> Hmmm: "ImportError: No module named tickcount"  looks like lp may still have some lucid issues
[18:16] <jml> kfogel, it's getting stuff from config that should be parametrized, it mixes up codehosting bits and generic logging bits, the oops stuff in there is pointless, the mangle_stdout parameter is unused and unnecessary
[18:16] <jml> the docstring is wrong
[18:17] <jml> a thing that's core to what the class does is a top-level function elsewhere in the module
[18:18] <jml> and I still don't really know what the code is doing (even though I kind of do because I wrote it)
[18:18] <kfogel> deryck: if you go to https://bugs.edge.launchpad.net/launchpad right now, it says: "There are currently no hot bugs filed against Launchpad itself."  While that's true, it's true because there are no bugs at all.  What has heat got to do with it?
[18:19] <deryck> kfogel, actually, it is true, thank you very much. :-)
[18:19] <deryck> incoming
[18:19] <deryck> https://bugs.edge.launchpad.net/launchpad/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&f
[18:19] <deryck> ield.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search
[18:19] <deryck> well, that didn't work.
[18:20] <deryck> kfogel, all the other bugs are closed.  See:  http://tinyurl.com/y8jc8rs
[18:20] <kfogel> deryck: ah.  IOW, going to that page now no longer shows a list of "recently filed" bugs or whatever.  It shows hot bugs, and if there are no bugs with heat, it shows none.
[18:21] <kfogel> deryck: s/recently filed/open and recently filed/
[18:21] <deryck> hmmm, actually....
[18:21] <kfogel> deryck: I basically assumed it's saying "hot" where it means "open", but apparently not?
[18:22] <deryck> kfogel, hot does mean open.  launchpad is not the same as launchpad-project.  yes, this makes 0 sense.
[18:22] <kfogel> deryck: wait a sec.  We're using "hot" to mean "open"?  This is going to cause, er, a lot of confusion :-).
[18:22] <kfogel> (aside from the launchpad vs launchpad-project distinction, which already causes enough confusion all on its own)
[18:23] <deryck> kfogel, no, sorry.  hot bugs list only has open bugs.  it doesn't mean open. :-)
[18:23] <deryck> Here are the bugs across the project group:  https://bugs.edge.launchpad.net/launchpad-project
[18:23] <kfogel> deryck: let me ask this as unambiguously as I possibly can :-)  : if there were any open bugs at all in 'launchpad', even if they had no heat whatsoever, would they show up at https://bugs.edge.launchpad.net/launchpad ?
[18:25] <deryck> kfogel, if you had 10 bugs against a project with 0 heat, and they were the only 10 bugs, they would show up in the hot bugs list.
[18:27] <kfogel> deryck: IOW, in order for a bug to have any heat at all, it must be open; so if that page is showing no bugs, it always means both there are no bugs open, and no bugs with heat.
[18:27] <kfogel> deryck: this makes sense, BUT
[18:27] <kfogel> deryck: the message at the top of that page is somewhat confusing, because it implies that there might be some open bugs, just none of them are "hot" enough to show here.
[18:28] <kfogel> deryck: it takes some subtle thinking and deep knowledge of the launchpad bug tracker to understand that "no hot bugs" in this circumstance implies no open bugs either.
[18:28] <deryck> kfogel, your first line after me is not correct.
[18:28] <kfogel> deryck: ok, thx.  Back up and tell me where I went astray :-).
[18:28] <deryck> kfogel, no hot bugs, doesn't always imply no open bugs.
[18:28] <deryck> kfogel, in this case, it's true.
[18:29] <kfogel> deryck: but...
[18:29] <deryck> and I'm abusing the comma there, but you get the idea.
[18:29] <kfogel> deryck: let me re-read two things you just said and decide if I want to accuse you of flagrant self-contradiction.  One sec.
[18:29] <kfogel> :-)
[18:29] <kfogel> deryck: "if you had 10 bugs against a project with 0 heat, and they were the only 10 bugs, they would show up in the hot bugs list"
[18:30] <deryck> true :-)
[18:30] <kfogel> vs "no hot bugs, doesn't always imply no open bugs"
[18:30] <kfogel> deryck: if you have no hot bugs, but you have open bugs, then... how is it that some of those open bugs are not hot bugs?
[18:30] <deryck> kfogel, those 10 bugs would be the hottest for *that* project (i.e. a project with only 10 bugs all of which have no heat)
[18:31]  * deryck processes
[18:31] <kfogel> deryck: first: can a bug ever be hot if it's not open?
[18:32] <deryck> kfogel, yes.  until the heat get re-caculated.
[18:32] <deryck> the time between fix released and the next update of heat.  a small window, but still, could happen.
[18:33] <kfogel> deryck: so, aside from this small window (implementation-caused, not design-caused), a hot bug is always an open bug, right?
[18:34] <kfogel> (whether it's hot for a particular project or hot in general -- point is, no context will display it as hot if it's not open)
[18:35]  * deryck thinks....
[18:35] <deryck> I'm not sure I'm comfortable with the "hot bug is *always* an open bug" but in practice I think this is true.
[18:35] <deryck> kfogel, ^^
[18:36] <deryck> kfogel, why does this matter? :-)  What problem do you want to solve here?
[18:38] <kfogel> deryck: the message at the top of https://bugs.edge.launchpad.net/launchpad is confusing.  The fact that I'm having trouble explaining to you why it's confusing may be considered a secondary bug.
[18:39] <kfogel> deryck: It's confusing because someone visiting that page is liable to think "Okay, so there are no _hot_ bugs here, but there might still be some open bugs that I'm just not seeing."  When in fact that's not true -- if there were any open bugs, the user would be seeing them.
[18:39] <jml> wow, that rendering is off
[18:39] <kfogel> deryck: Attempting to prove that latter assertion is what's got us tangled up, I think.
[18:40] <jml> hmm, but only in webkit
[18:42] <deryck> kfogel, it opens so rarely I don't think its worth worrying about.  something like /launchpad is the only place you would ever see this.
[18:42] <deryck> s/opens/happens/
[18:42] <jml> and new projects, right?
[18:43] <deryck> jml, no because initially you get a "no bugs filed" message.  once you have one bug you have a hot bugs list.
[18:44] <deryck> jml, the only condition that leads to this is someone getting all there bugs closed.  so maybe a very small project could see this too
[18:44] <jml> deryck, or a very successful one :)
[18:44] <deryck> jml, come on. :-)
[18:45] <jml> deryck, we should embed a flash game! if you get to this screen, you deserve to muck around a little!
[18:45] <jml> :P
[18:45] <deryck> jml, now that I like! :-)
[18:46] <deryck> I'm not trying to be a dick about it.  if the language is bad, it's a trivial fix.  but I'm not sure it's as complicated as we're making it.
[18:47] <deryck> find another project on launchpad other than "launchpad" where this applies and I'll change it myself later today. :-)
[18:48] <jml> my 2c, just change the text to say "no open bugs" rather than "no hot bugs".
[18:48] <deryck> I'm not sure that would always be accurate either.
[18:49] <deryck> now you're forcing me to go consult code.
[18:49] <jml> anything but that :)
[18:49] <kfogel> deryck: I have to admit, the fact that we don't know which phrasing is more accurate is kind of disturbing in its own right.  But no, I don't have any other example pages right now :-).
[18:50] <james_w> kfogel: tickcount: install python-support from the LP ppa and reinstall python-tickcount, cf abentley's email to launchpad-dev a couple of days ago.
[18:52] <jml> ok, now I'm angry at Python
[18:53] <kfogel> james_w: ah, thanks!  missed that one
[18:53] <kfogel> jml: why, because it's not Lisp?
[18:53] <jml> kfogel, because it has bad errors
[18:54] <deryck> kfogel, jml -- I think it's fine to make it "no open bugs." it's just a searchTasks for open bugs ordered by heat desc.  but it's not an explicit count, which is why it makes me nervous to change the language.
[18:54] <deryck> it's hand wavey to say "no open bugs" but it probably is more accurate most times.
[18:55] <jml> hmm. error understood, now I can go back to hating our test suite
[18:55] <deryck> kfogel, there's a hot bug on /launchpad now :-)
[18:56] <kfogel> deryck: not for long...
[18:56] <deryck> kfogel, I think that means it's better to have "no open bugs" :-)
[18:57] <jml> (there's an smptd server that runs while the puller tests are running, just cos)
[18:57] <deryck> oh crap, need to run
[18:57] <kfogel> deryck: Well, I agree.  I mean, the message disappeared when a bug -- any bug at all -- showed up, and the message's disappearance was independent of the bug's heat.  And now that I've made the bug go away, the message is back :-).  So it's clearly about openness, not heat.
[18:57] <kfogel> deryck: bye!
[18:57] <kfogel> missed him
[19:04] <gary_poster> sinzui: hey.  should I move https://bugs.edge.launchpad.net/launchpad-foundations/+bug/488399 to 10.04?
[19:04]  * gary_poster expected mup
[19:04] <gary_poster> "automate yui unit tests"
[19:04] <sinzui> yes
[19:04] <mup> Bug #488399: automate yui unit tests <build-infrastructure> <javascript> <Launchpad Foundations:In Progress by sinzui> <https://launchpad.net/bugs/488399>
[19:09] <kfogel> jml: request for Captain Obvious: what am I missing here in my failure to get this test to run?  http://paste.ubuntu.com/406652/
[19:09] <jml> kfogel, zope does exact string matching on the path
[19:10] <kfogel> jml: so I thought I tried some exact paths
[19:10] <kfogel> jml: does it need to be *absolute*?
[19:10] <jml> kfogel, more accurately, the exact string of the path used to open the doctest is stored in the test object and zope.testing does regex matching on that
[19:10] <jml> kfogel, lemme try to get this
[19:11] <kfogel> jml: ./bin/test -vvct lib/lp/bugs/stories/bugattachments/10-add-bug-attachment.txt  fails too
[19:11] <kfogel> jml: s/fails/succeeds by running 0 tests/
[19:11] <jml> try "-cvvt stories/.\*/bugattachements"
[19:11] <jml> actually, just "-cvvt stories/bugattachments"
[19:12] <jml> kfogel, you'll notice that the name of the tests are like "lib/lp/bugs/tests/../stories/bugattachments/xx-attachments-to-bug-report.txt"
[19:12] <kfogel> jml: yeah, I assumed those were run either all first or all last
[19:12] <jml> kfogel, no, look more closely, "tests/../stories"
[19:13] <jml> kfogel, how is the regex "lib/lp/bugs/stories/bugattachments/10-add-bug-attachment.txt" ever going to match the string "lib/lp/bugs/tests/../stories/bugattachments/10-add-bug-attachment.txt"?
[19:13] <kfogel> jml: huh, wait, where are you getting the path with the ".." form from?
[19:14] <jml> kfogel, it's what zope.testing prints when I manage to find the test successfully by running "./bin/test -cvvt stories/bugattachments"
[19:15] <kfogel> jml: yes, that ran it for me too.  But my output doesn't have any "../" in it
[19:15] <jml> kfogel, can you paste the command and output please?
[19:16] <kfogel> jml: yes. And actually I should say, it didn't run the test, but it got an error that looked like it happened because it was sincerely trying to run the test.
[19:16] <kfogel> jml: http://paste.ubuntu.com/406658/
[19:17] <jml> kfogel, oh right, it didn't even get close to running the test
[19:17] <kfogel> jml: so "no such file or directory" -- but every other cmdline just seems to "succeed" with 0 tests run
[19:17] <kfogel> i.e., why don't I always get that no-such-file-or-dir error?
[19:17] <jml> kfogel, that's a different problem
[19:17] <kfogel> OH
[19:18]  * kfogel carefully duplicates his brain, seeing he's going to need a spare
[19:18] <jml> kfogel, when you run ./bin/test with "-t" and it finds no tests that match the regex, it never tries to run any of the layers
[19:18] <jml> kfogel, when you run it and it *does* find tests, it runs the layers for the tests that it found
[19:18] <kfogel> jml: *nod*
[19:19] <kfogel> jml: so it found the test, and then died trying to set up layers to run it?
[19:19] <jml> kfogel, correct
[19:19] <kfogel> jml: hey, sounds to me like it DID get closer to running the test :-).  You know, closer than "infinitely far away".
[19:20] <jml> kfogel, specifically, you have a problem with memcached layer that I have no clue about.
[19:20] <kfogel> jml: ok, thanks
[19:20] <jml> kfogel, anyway, I guess now that I've got one patch into zope.testing, I could try to fix the abomination of doctest naming
[19:20] <jml> although that might be a bug in Python
[19:21] <jml> in which case I'll write a patch and try to convince Michael Foord that it's uncontroversial
[19:21] <jml> and then we'll be able to make use of it in three years time when we run LP on Python 2.7
[19:23] <kfogel> jml: ooooouch
[19:34] <jml> sweet
[19:35] <jml> I think I've got an SSH server in lp.services.sshserver that does all of the neat logging, timeout, oops reporting and authentication-against-LP that codehosting does, but without actually knowing anything about hosting code
[19:44] <jml> it's 4210 lines of diff though :(
[20:00] <jml> g'night all
[20:11] <ricotz> henninge, thank you for your help earlier today
[20:15] <henninge> ricotz: np, glad I could help
[20:45] <james_w> gary_poster: for these 502 errors is there any use you want to make of us logging them?
[20:48] <gary_poster> james_w: oh, this is in regard to my comment about kees' patch, right?  Or is in regard to my general desire to get logs of the 502 errors so we can see if we can determine root causes?
[20:49] <james_w> gary_poster: in that bug you said you would like to know when it happens. In what form would you like that info to come?
[20:51] <gary_poster> james_w: my current feeling is that attachments to the bug would be good.  I was expecting logs of the sort that leonard requested earlier in the bug report.
[20:51] <james_w> for instance I got a 502 at 2010-03-30 19:10:20.474341 UTC from production
[20:52] <james_w> ok, gathering logs all the time is excessive for this process, I'll set something dedicated up if you like
[20:56] <gary_poster> james_w: thank you.  if you are going to be organized about it, then let us be as well.  I'll get details of what we think might help to you (via the bug comments).  I intend to get this done by tomorrow.
[20:57] <james_w> thanks
[21:03] <thumper> morning
[21:24] <didrocks> mwhudson: hey o/ I was just wondering when do you think the ssh key code will be exposed in the api in https://edge.launchpad.net/+apidoc/devel.html (not sure about the publishing process)
[21:24] <mwhudson> didrocks: i think your branch landed on db-devel, so after the rollout in a couple of days
[21:25] <didrocks> mwhudson: ok, I was expecting it to be published automatically in devel (like being a trunk). So no worry :) thanks!
[21:45]  * deryck broadcasts from daughter's dance studio wifi
[22:15] <maxb> For some reason launchpadlib 1.5.6 is missing its bzr tag. Please could someone who is a member of ~lazr-developers add it:
[22:15] <maxb> bzr tag -d lp:launchpadlib -r revid:leonard.richardson@canonical.com-20100304202437-68ykm4fpbio8jdid 1.5.6
[22:15] <maxb> I've checked the branch against the tarball to verify the revision
[23:48] <mwhudson> no what's going on