[00:15] <wgrant> Can I convince someone to ec2test and land to *db-devel* https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection-part1/+merge/14729? All except for the final two merges have been reviewed.
[00:55] <jml> intellectronica, what was the subunit issue?
[00:59]  * mwhudson lunches
[01:34] <jml> thumper, hi
[01:43]  * maxb wonders where python-2.5 is in PQM
[01:48] <mwhudson> maxb: it's not in pqm :(
[01:49] <spm> maxb: lp.codehosting.tests.test_acceptance.AcceptanceTests.test_push_triggers_mirror_request(sftp) is last not-buffered  test outputted
[01:49] <maxb> ooh, getting there, then
[01:49] <spm> maxb: what mwhudson said tho - it's a manual merge, not pqm. same box tho.
[01:50] <mwhudson> ah
[01:51] <spm> no failures yet either. looking good.
[02:17] <jml> man
[02:17] <jml> I picked the wrong week to make a USB stick w/ the launchpad repo on it.
[02:19]  * jml back in a bit
[02:26] <mwhudson> jml: there's a right week for that?
[02:32] <spm> sweet. the branch succeeded.
[02:36] <thumper> jml: hi
[02:36] <thumper> spm: the python 2.5 branch?
[02:36] <spm> thumper: yup. have pushed the new shiny everywhere too now
[02:36] <thumper> spm: awesome
[02:36] <wgrant> Awesome.
[02:36] <wgrant> Curses.
[02:36]  * thumper goes to remind himself what is new in 2.5 to use
[02:37] <wgrant> ifs in expressions!
[02:37] <spm> and pqm is re-open for srs bsns
[02:37] <wgrant> srs OMG 2.5 BROKE THE WORLD bsns?
[02:38] <spm> no
[02:38] <spm> only for srs ZOMG 2.5 BROKE THE WORLD bsns
[02:38] <thumper> wgrant: ew
[02:38] <spm> the Z is critical pathness hotness shinyness
[02:38] <thumper> wgrant: the syntax for that is horrible
[02:39] <wgrant> thumper: Better than using four lines instead.
[02:39] <thumper> wgrant: well... that is  a matter of opinion :)
[02:39] <wgrant> Pfft.
[02:40] <thumper> PEP 309: Partial Function Application
[02:40] <thumper> oohh..
[02:40] <wgrant> Ah, yes, functools?
[02:40] <thumper> PEP 328: Absolute and Relative Imports
[02:40] <thumper> hmm
[02:40] <thumper> I see an extended coding standard being applied for imports
[02:41] <wgrant> Oh, that's in 2.5 too?
[02:41] <thumper> PEP 343: The 'with' statement
[02:41] <thumper> \o/
[02:42]  * jtv hates that one
[02:42] <thumper> defaultdict
[02:42] <thumper> jtv: how can you hate the with statement?
[02:43] <jtv> Its design smells of over-complication for the wrong reasons.
[02:43] <thumper> jtv: it gives the abiltiy to have controlled release of resources
[02:43] <jtv> Plus, the main reason I would normally like it is that it saves indentation levels—but it doesn't
[02:43] <thumper> and my favourite reason right now...
[02:43] <thumper> bzr-svn
[02:43] <mzz> it kinda does, somewhat (contextlib.nested)
[02:44] <jtv> It doesn't give the ability to have controlled release of resources; it provides syntactic sugar for continued awkward, manual release of resources.
[02:44] <mwhudson> $ cd ../bzr-svn-imports/
[02:44] <mwhudson> $ bzr missing --theirs-only
[02:44] <mwhudson> You are missing 1130 revision(s):
[02:44] <mwhudson> ...
[02:44] <wgrant> Nice.
[02:44] <wgrant> You are in for a long evening.
[02:44] <thumper> mwhudson: are you saying that jelmer has 1130 new revisions since we last looked?
[02:44] <mwhudson> it shouldn't be that bad
[02:44] <wgrant> I presume that's 1130 LP revisions.
[02:45] <mwhudson> thumper: no, this is my branch that adds bzr-svn support to launchpad
[02:45] <thumper> heh
[02:47] <maxb> Now if only I could finish fixing bzr-rebase, I could rebase the python-migration2.6 branch on top of devel
[02:48] <wgrant> maxb: Why would you rebase?
[02:48] <mwhudson> wow one conflict
[02:49] <mwhudson> in sourcecode/Makefile ffs
[02:49] <thumper> mwhudson: \o/
[02:49] <maxb> wgrant: Because most of the content of the branch is either merges from trunk, or stuff that got cherrypicked onto the 2.5 branch
[02:49] <wgrant> maxb: But rebasing is bad.
[02:51] <maxb> Sometimes? Yes. Universally? No.
[02:51] <mwhudson> heh, i guess i can remove my hack that adds collections.defaultdict from this branch
[03:01]  * mwhudson heats up his laptop running a 2.5 make build for the first time
[03:06] <mwhudson> wee buildbot fall over
[03:07] <wgrant> How badly?
[03:07] <mwhudson> src/zope/security/_proxy.c:19:20: error: Python.h: No such file or directory
[03:07] <mwhudson> so missing python2.5-dev i guess
[03:07] <wgrant> Ah.
[03:07] <wgrant> Easy.
[03:07] <wgrant> Yep.
[03:10] <maxb> huh. Shouldn't it have launchpad-developer-dependencies installed?
[03:10] <wgrant> It's buildbot. That would be too normal.
[03:11] <maxb> Sometimes I wish LP used bzr shared repositories instead of stacking :-/
[03:11] <wgrant> Why?
[03:11] <maxb> bzr is currently uploading upwards of 12MB for a simple UDD package merge
[03:12] <wgrant> Is it actually stacking?
[03:12] <maxb> it claims to be
[03:13] <maxb> maybe I should have stacked it on the debian branch instead
[03:17]  * spm is reminded how much he hates updating AMI's....
[03:21] <mwhudson> spm: i wrote a script to do it ...
[03:21] <mwhudson> (ec2 update-image)
[03:21] <spm> mwhudson: you did? is that on prase? or local for you?
[03:21] <mwhudson> sadly the buildbot and ec2 setups are more or less disjoint...
[03:22] <spm> it's been a month or 3 sinece the last one I did. so am a tad rusty.
[03:23]  * mwhudson has finally wrestled his inbox into some kind of submission
[03:24] <wgrant> mwhudson: Sounds like you need another sprint.
[03:28] <maxb> Buildbot is blaming me for something
[03:28] <mwhudson> maxb: see above
[03:29] <maxb> oh, that
[03:29] <maxb> wonder why it's blaming me! :-)
[03:29] <wgrant> It blames everyone with merged revisions since the last run.
[03:29] <mwhudson> no idea
[04:00] <thumper> rockstar: you around hacking?
[04:24] <jml> hey
[04:24] <jml> how do I query status on bugtarget.searchTasks?
[04:29] <wgrant> jml: List of strings.
[04:30] <wgrant> Wow, those docs suck.
[04:30] <jml> wgrant, what are the strings?
[04:30] <jml> wgrant, yes, they do.
[04:30] <wgrant> jml: ["Triaged", "Won't Fix"] and the like.
[04:30] <jml> yech
[04:30] <wgrant> Hm?
[04:31] <jml> I dislike this API.
[04:31] <jml> also len(collection) doesn't work as advertised.
[04:32] <wgrant> What does it do instead?
[04:32] <wgrant> Note that collections resulting from named operations are... odd.
[04:33] <jml> it raises an error.
[04:33] <jml> I guess those are the kinds of collections I've got.
[04:34] <jml> wgrant, do you know of a way to get the size without iterating through the list?
[04:36] <MTecknology> Make sure I understand this... RAID 1+0 == [ mirror ( span drive_1 & drive_2 ) & ( span drive_3 & drive_4 ) ]   ?
[04:36] <MTecknology> Sorry, wrong channel - but... can you guys answer that?
[04:38] <wgrant> jml: See statik's last comment on bug #303414, but bug #274074 is the real bug.
[04:38] <mup> Bug #303414: Collections returned by named operations don't act like other collections <launchpadlib :Triaged> <https://launchpad.net/bugs/303414>
[04:38] <mup> Bug #274074: Missing total_size on collections returned by named operations <api> <launchpadlib :New for leonardr> <https://launchpad.net/bugs/274074>
[04:38] <jml> wgrant, thanks.
[04:38] <wgrant> jml: Ah, the latter has a workaround.
[04:44] <mwhudson> note that total_size might be a lie in any case, i think
[04:46] <jml> mwhudson, it's giving me the same numbers as len(list(collection)) in this case
[04:46] <mwhudson> jml: ok
[04:46] <mwhudson> jml: i'
[04:46] <mwhudson> m thinking of private bugs
[04:46] <jml> mwhudson, but I do think you're right.
[04:46] <mwhudson> but i might be barking up the wrong tree
[04:46] <jml> mwhudson, ahh, of course.
[04:49] <wgrant> Some queries I know of are adjusted to exclude invisible objects from even the SQL result.
[04:49] <wgrant> But I don't think that is the case here, so the numbers will indeed be wrong.
[04:49]  * mwhudson grinds to a halt
[04:49] <mwhudson> wgrant: the branch listings you mean?
[04:50] <wgrant> mwhudson: The specific example I was thinking of was related to builds, but that too.
[04:53] <MTecknology> offtopic - Has anyone ever thought about using LP to manage user accounts on a server?
[05:10] <thumper> MTecknology: don't think so...
[05:11] <MTecknology> thumper: I think I want to try that when I get a server to develop LP on
[05:11] <MTecknology> it sounds like fun - sounds easy too
[05:12]  * thumper EODs (for now)
[05:13] <MTecknology> thumper: does that mean bored or sleeping
[05:14] <thumper> MTecknology: it means making dinner
[05:15] <MTecknology> oh
[05:16] <wgrant> bigjools: Are you really here?
[06:10] <intellectronica> jml: the issue with subunit was that i didn't have it. neither as a package nor in sourcecode.i fixed it by installing the package, which is presumably different from everyone else who seem to have it in sourcecode
[07:33] <lifeless> intellectronica: subunit issue?
[08:17] <adeuring> good morning
[08:57] <stub> ImportError: /usr/lib/python2.4/site-packages/psycopg2/_psycopg.so: undefined symbol: Py_InitModule4
[09:00] <wgrant> stub: You've followed the 2.5 upgrade instructions?
[09:00] <stub> I'm sure those instructions are around here somewhere...
[09:00]  * stub rummages
[09:01] <wgrant> stub: They were sent to launchpad-dev@, prefixed with 'PLEASE READ'
[09:01] <stub> Got that - just talking about make clean and friends
[09:11] <ajmitch> make clean & an important 'rm'
[09:15] <stub> Thats not it
[09:15] <stub> For some reason buildout is deciding to put usr/lib/python2.4/site-packages in my path
[09:15] <wgrant> ajmitch: That rm landed hours ago.
[09:15] <wgrant> stub: Awesome.
[09:17] <ajmitch> wgrant: I thought that mail said to do the rm manually if you'd updated in the meantime
[09:17] <ajmitch> it didn't affect me, so I didn't worry too much about it
[09:22]  * wgrant pushes SHHH off a cliff.
[09:26] <wgrant> Hmmmmmm.
[09:26] <wgrant> I just started getting that 'a.git' sourcecode removal error that somebody reported yesterday.
[09:27] <wgrant> I wonder if it's a nested branch hidden somewhere.
[09:29] <wgrant> Looks like dulwich tests.
[09:39] <poolie> hi wgrant
[09:39] <stub> Does anyone else see python2.4/site-packages in their bin/py ? It might not cause errors if the ordering is different.
[09:41] <wgrant> stub: I'm currently 2.5ifying. Will tell you in a sec.
[09:41] <wgrant> Hi poolie.
[09:41] <wgrant> stub: Nothing in mine.
[09:42]  * stub pouts
[09:42] <wgrant> stub: Nothing crazy in ~/.buildout?
[09:43] <stub> I don't have one
[09:43] <wgrant> Huh.
[09:45] <wgrant> stub: Tried a fresh copy of devel?
[09:45] <wgrant> buildout annoys me.
[09:46] <stub> develop-eggs existed with a file referencing 2.4. Nuking this directory seems to have cleaned things up. Might be because my branches tend to be old.
[09:47] <wgrant> Ah.
[09:47] <wgrant> stub: None of my develop-eggs/ contain 2.4.
[09:48] <stub> Looks like buildout generated magic that make clean doesn't clean
[09:48] <wgrant> Is this a seriously old checkout?
[09:56] <stub> The file was dated July. Like I said - my branches tend to be old ;)
[10:08] <wgrant> stub: Ah, I didn't consider 'old' to mean 'before the epoch'
[14:00] <Ursinha> hi guys
[14:00] <allenap> abentley: Do you have a few minutes to help me understand why a code import is breaking? It keeps failing with logs that look like: http://launchpadlibrarian.net/35783114/nhibernate-trunk-log.txt
[14:00] <Ursinha> after having a db patch approved, what do I have to do?
[14:01] <allenap> Ursinha: Hi. Land it to db-devel I think.
[14:01] <Ursinha> allenap, hi :) do I have to rename it and stuff?
[14:01] <rockstar> allenap, that looks like a bug in cscvs
[14:01] <allenap> rockstar: Ah.
[14:02] <Ursinha> allenap, that's a bug that cscvs that times out when importing large svn repositories
[14:02] <Ursinha> s/that cscvs/in cscvs/
[14:02] <rockstar> allenap, I think there might even be an open bug about it, but I'm about to lose internets, so I can't search.
[14:02] <Ursinha> rockstar, there is
[14:02] <rockstar> Ursinha, :)
[14:02] <Ursinha> allenap, I think I mentioned the bug number in my handover email
[14:02] <allenap> rockstar: Thanks :)
[14:02] <Ursinha> rockstar, :)
[14:02] <allenap> Ursinha: You probably did, I just have a sieve for memory :)
[14:02] <Ursinha> hehe
[14:03] <Ursinha> so :) do I have to just land it to db-devel or have to rename it as stub defined, move between directories...?
[14:03] <allenap> Ursinha: Re. db patch, have you looked at database/schema/README.
[14:03] <Ursinha> allenap, yes, but the post-approval I'm not clear about
[14:04] <allenap> Ursinha: Did stub give you a patch number?
[14:04] <Ursinha> allenap, yes
[14:06] <allenap> Ursinha: So, yes you have to rename the patch with that number, then land it. (Sometimes stub offers to land these changes on your behalf, but it's been a long time since I did a db patch and I don't know if he does that any more).
[14:07] <allenap> Ursinha: Is that what you were looking for, or did I get the wrong end of the stick?
[14:08] <Ursinha> allenap, yes, just that! So I just rename it and keep in the pending folder?
[14:09] <allenap> Ursinha: Rename it and put it in database/schema too.
[14:10] <allenap> Ursinha: So it should be something like database/schema/patch-2207-05-0.sql (where 05 is whatever stub gave you).
[14:10] <bac> gary_poster: i'm getting failures on ec2 related to 2.5.  have you successfully run on ec2 since the switch?
[14:12] <gary_poster> bac, no.  We did run it successfully on ec2 before the switch with adding the python 2.5-devel dependency.  ec2 is supposed to (did last time I checked) update launchpad-dependencies, so I thought we would be covered even without a new image.
[14:12] <bac> gary_poster: it is dying building zope.security
[14:12] <bac> src/zope/security/_proxy.c:19:20: error: Python.h: No such file or directory
[14:13] <gary_poster> bac: OK, yes, looks like python2.5-devel is missing.  I should have checked that again.  I'm almost done with a related task, and then will go to that.  You should be able to work around that for now; thinking.
[14:16] <gary_poster> bac: the only way I can think of is a --postmortem, which is annoying.  salgado, is that how you tested ec2 before, withdoing things manually after a --postmortem?
[14:17] <gary_poster> allenap, do you know where the instructions are to create a new ec2 image?  I'm not familiar with the new automation that mwhudson did.
[14:17] <allenap> gary_poster: I'll have a look in the code...
[14:17] <abentley> allenap: looks like the remote server is dropping the connection.
[14:20] <salgado> bac, gary_poster, I used a demo instance
[14:20] <gary_poster> salgado: ah ok, thank you
[14:21] <gary_poster> bac, I'm on this now
[14:21] <bac> gary_poster: great.  thanks.
[14:22] <allenap> gary_poster: I think just ec2 update-image. You can specific an AMI name prefixed with "based-on:" if it's a blank install.
[14:23] <allenap> abentley: Thanks. rockstar and Ursinha suggested it was a timeout bug, so https://bugs.edge.launchpad.net/launchpad/+bug/343207.
[14:23] <mup> Bug #343207: large SVN Import fails with a timeout <Launchpad itself:Invalid> <Launchpad CSCVS:New> <https://launchpad.net/bugs/343207>
[14:23] <allenap> abentley: The nhibernate import always fails on SSL negotiation though. Could that still be a timeout?
[14:24] <gary_poster> allenap: right just saw that, thank you. Will dig in there.  My guess is that we do *not* want a blank install, agree?
[14:24] <allenap> gary_poster: Yeah, agreed.
[14:25] <gary_poster> cool, thx
[14:26] <abentley> allenap: I guess it could be that the remote server doesn't support PROPFIND or something.
[14:26] <allenap> gary_poster: Looks like you'll also need the ec2-* command line tools installed.
[14:26] <allenap> gary_poster: It needs ec2-register specifically.
[14:27] <gary_poster> allenap: oh, ok, good to know.  I don't have them locally.  so this is my revised plan:
[14:27] <gary_poster> 1) install ec2-* command line tools
[14:27] <gary_poster> 2) determine the appropriate next AMI name by scrounging around
[14:28] <allenap> abentley: Strange. Other SF imports work okay. Is this worth spending time investigating, or shall I just attribute it to the aforementioned bug?
[14:29] <allenap> gary_poster: That sounds about right :)
[14:29] <gary_poster> 3) use ec2 update-image with an additional command to update dependencies, if necessary (``--extra-update-image-command='sudo aptitude upgrade'``)
[14:29] <gary_poster> done
[14:29] <gary_poster> full-upgrade I should have said
[14:30] <abentley> allenap: It is that bug.  I'm not aware of any workarounds.  But you could bring it up with the Bazaar team.
[14:30] <Ursinha> allenap, I did the renaming and the moving but the patch didn't make it
[14:31] <Ursinha> allenap, do I have to do something else, like regenerating sample data?
[14:31] <allenap> abentley: Okay, I'll email the team, CCing the list.
[14:32]  * allenap looks
[14:32] <allenap> Ursinha: What was the error?
[14:33] <Ursinha> allenap, hmmm HMMM I think I figured out :)
[14:33] <Ursinha> I forgot changing the line in the patch with the correct number :)
[14:33] <allenap> Ursinha: If you get stuck again, I'll grab your branch and take a look.
[14:33] <allenap> Ursinha: Hehe, cool :)
[14:34] <mrevell> danilos, hey, how are you fixed for the first hour this morning?
[14:41] <bac> gary_poster: could ec2 grow another option to run arbitrary commands at some point?  ec2 --arbitrary "sudo apt-get install python2.5-devel"
[14:43] <gary_poster> bac: sure.  a hopefully minor trick would be to specify when the arbitrary command should run.  Maybe immediately prior to build is always good; not sure
[14:44] <bac> gary_poster: or perhaps something less arbitrary, like a set of packages to install...
[14:44] <gary_poster> yeah
[14:44] <gary_poster> would prefer that myself
[14:58] <flacoste> gary_poster: python2.5!!!
[14:58] <gary_poster> flacoste: :-) yup
[14:58] <flacoste> awesome!!!
[14:58] <flacoste> gary_poster: we can drop lsprof from sourcecode that means?
[14:58] <gary_poster> flacoste: yeah, should be able to do that
[14:58] <flacoste> gary_poster: has it merged in db-devel yet?
[14:59] <gary_poster> flacoste: should have; it merged in devel last night, and we had a successful buildbot run earlier this morning.  Looking
[15:00] <flacoste> gary_poster: it seems to be part of rev 8665 which hasn't been blessed yet
[15:00] <intellectronica> lifeless: yeah, subunit missing when i tried to run tests. wasn't available to me either from a package or in sourcecode (which is how most people get it)
[15:01] <gary_poster> flacoste: you asked if it were in db-devel though: yes, it is, as of rev 9685
[15:01] <gary_poster> 8685 I mean
[15:02] <gary_poster> you probably meant 8685 too :-)
 gary_poster: we can drop lsprof from sourcecode that means?
 flacoste: yeah, should be able to do that
[15:28] <maxb> I already did that :-)
[15:28] <gary_poster> maxb: go you :-)
[15:29] <gary_poster> maxb, a huge thank you for all your work on the Python 2.5.  It would not have gone nearly as smoothly or quickly without you.
[15:30] <maxb> And thank _you_ (and gary and salgado) for wrangling the ZTK demons into submission
[15:30] <maxb> erm
[15:30] <maxb> and *barry*
[15:30] <gary_poster> :-) cool, very happy to work with you
[15:40] <abentley> allenap: I see you've emailed the code team, but I meant the Bazaar team.
[15:40] <allenap> abentley: Rats.
[15:41] <allenap> abentley: Sorry for spamming. Shall I just email the bazaar mailing list?
[15:41] <allenap> abentley: Scratch that.
[15:42] <allenap> abentley: I'll email the Canonical Bazaar team directly. Is it worth CC'ing any mailing lists?
[15:44] <abentley> allenap: You could cc the canonical-bazaar mailing list.
[15:47] <jml> intellectronica, I had thought I added subunit to sourcecode
[15:48] <intellectronica> jml: you prolly did. something is obviously wrong with my setup
[16:00] <henninge> sinzui: ping
[16:00] <sinzui> Hi henninge
[16:01] <henninge> Hi sinzui
[16:02] <henninge> sinzui: I just saw that you changed the view code for the featured projects display on the LP home page.
[16:02] <sinzui> I did
[16:02] <henninge> sinzui: it looks like the goal is to put them into one column?
[16:03]  * henninge has not looked at the template yet
[16:03] <sinzui> No, the view should not dictate the what the layout doe. The layout is identical to what it was yesterday
[16:04] <sinzui> henninge: I replaced the custom styles with to global styles that do the same layout
[16:04] <sinzui> I removed the local styles from the gloabl style sheet and inlines them into the only page that will ever use them
[16:05] <henninge> sinzui: I see
[16:07] <henninge> sinzui: but this looks like the list is shortened to 11 entries.
[16:08] <henninge> sinzui: currently it's 21
[16:08] <henninge> sinzui: and that is too short, too.
[16:08] <sinzui> I did not intend to shorten it,
[16:08] <henninge> sinzui: atm Ubuntu and zope are missing from the list on the home page
[16:08] <sinzui> My code is not on edge
[16:09] <henninge> sinzui: before the last roll-out I filed bug 467079
[16:09] <mup> Bug #467079: List of featured projects on LP home page should be dynamic in length. <post-3-ui-cleanup> <Launchpad Foundations:In Progress by henninge> <https://launchpad.net/bugs/467079>
[16:09] <henninge> sinzui: but I did not get r-c for it (I was too late ...)
[16:09] <henninge> for the fix, I mean
[16:10] <sinzui> I agree it should be dynamic. I removed the code that split the list into two lists. I did not change the length of features, may I should have double to the number
[16:11] <sinzui> I will QA it when edge updates, if the list is wrong I will fix it.
[16:11] <henninge> sinzui: I can just land my branch in incorporate your change.
[16:12] <sinzui> Okay then. If you think the list needs to be longer just do it. If you need a reviewer, I can do it
[16:12] <henninge> sinzui: cool, won't be long.
[16:14] <henninge> sinzui: cool, won't be long.
[16:14] <sinzui> fab.
[16:15] <henninge> sinzui: can you remind me where to find the template for the home page?
[16:15]  * sinzui looks at his own diff
[16:15] <sinzui> lib/canonical/launchpad/templates/root-index.pt
[16:16] <henninge> just found it ...
[16:16] <henninge> ;)
[16:16] <sinzui> ^ I should have moved it to registry, but I did not want to make the branch too long
[16:19] <henninge> sinzui: I didn't know the two-colmun layout can be achieved by pure css magic. cool
[16:20] <sinzui> henninge: It is used on a lot of pages. It was one of the classes in style-3.0.css that was landed with the file
[16:21] <sinzui> henninge: since that CSS file is global, should only contain styles that can be used by all launchpad, do not use ids, use classes
[16:22] <henninge> sinzui: I understand
[16:22] <henninge> sinzui: actually, I was surprised at the time to find these styles in the global css
[16:23] <henninge> putting them in the header is what I prefer, too. (If they are local)
[16:23] <sinzui> The goal may have been to refactor them into classes that can be used by all the root pages.
[16:24] <sinzui> That may be a goal now. If so, it is pretty secret. I have need seen any designs for the root pages.
[16:40] <henninge> sinzui: using the css for the two column display transposes the matrix
[16:40] <sinzui> Yes it does :(
[16:40] <henninge> sinzui: I don't think many people will notice, though.
[16:40] <sinzui> I was going to announce that so that if someone cared he could fix it
[16:41] <henninge> sinzui: also, it adds more space between the entries, is that intended?
[16:42] <sinzui> It is intended in the sense that we want all launchpad to display consistently...
[16:43] <sinzui> But I think a bug was introduced into the CSS a few weeks ago. All the lists have extra space now and I am see fragments of sprites appearing.
[16:43] <sinzui> There is a bug reported about the sprites, but I think we may want to fix the root cause ans revert it.
[16:44] <henninge> sinzui: yes, I noticed those fragments, too
[16:44]  * henninge starts firebug
[16:45] <sinzui> I suspect it was EdwinGrubbs's change to wrap the action menus, but since his intent was to localise the affect to the action menu, I do not think any other list should have been affected
[16:54] <henninge> sinzui: so the extra vertical space in the featured project list is the addition of padding-bottom and margin from these two styles. http://paste.ubuntu.com/320918/
[16:54] <henninge> sinzui: making it 1.05em total
[16:56] <henninge> that is in style-3-0.css
[16:56] <sinzui> That is too must but those changes are older that a few weeks old
[16:57] <sinzui> To review changes to those classes, look at the index page for products and person. The <object> information portlets use these lists a lot
[17:00] <henninge> sinzui: I just think that the featured project list might be a different case and I'd rather just reset that padding-bottom locally.
[17:00] <sinzui> henninge: I think we *may* want to separate `.two-column-list li` from `.two-column-list dl` I think the <dl> has too much space when I look at my profile (https://edge.launchpad.net/~sinzui), so I am in favour of find on rule for both conditions
[17:01] <sinzui> henninge: https://edge.launchpad.net/gdp also shows the same issue (because it is the same markup). I think I expect to see something about 0.5em
[17:02]  * henninge looks
[17:02] <sinzui> Since we use 1em for  to separate blocs, lists must use less to show that they are together
[17:03] <henninge> sinzui: that makes sense
[17:03] <henninge> sinzui: I wonder what the general "li: padding-bottom 0.3 em" is about
[17:07] <sinzui> I think it the number that is the expected separation, They are not sentences in a paragraph, so there should be separation. I think that number is the actual number that was approved, where my head thinks the number is 0.5em
[17:08] <henninge> sinzui: so it is the extra 0.75em from the two-column-list definition that cause the problem.
[17:09] <gary_poster> maxb: got an official +1 on ~launchpad-committers for lp-source-dependencies, meta-lp-
[17:09] <gary_poster> debs, and most/all other important branches.  PPA will not be controlled with ~launchpad-committers, but going to give you individual permission to upload.
[17:09] <sinzui> henninge: I think so.
[17:10] <henninge> sinzui: also, I just saw that what we see on the prod/edge homepage is different to what we see on the dev homepage because on the dev homepage the images for the projects are displayed using sprites while the real projects have their own logos.
[17:10] <henninge> sinzui: I see different styles used for sprites and for project logos.
[17:10] <sinzui> yuck
[17:11] <henninge> sinzui: the project logos seem to squeeze the lines further apart
[17:11] <sinzui> henninge: That requires a tales fix. This issue is global to launchpad. I would not use the featured project list to test the fix
[17:12] <henninge> sinzui: that said, removing the 0,75 em padding and leaving the 0.3 margin should give us the desired result with the real data.
[17:12] <sinzui> henninge: Yes! your remark explained exactly what I have seen in some information portlets. I could not understand the extra px difference
[17:13] <Ursinha> bigjools, I  haven't said hi in person to you :)
[17:14] <henninge_> ah, the daily reconnect. Reminds me that it's time to go home ... ;)
[17:14] <henninge_> sinzui: glad to hear I could help you
[17:14] <sinzui> henninge: I am tempted to say the project sprite vs icon issue need to be fixed in a separate branch. It is certainly a separate bug. I know there are hacks in some information portlets that use clear:both to place the next item under the project with an icon
[17:15] <henninge_> sinzui: Let me prepare this branch for review
[17:16] <henninge_> sinzui: yeah, I am not going to to into that now. I just wanted to land a branch that was left over from last cycle ... ;-)
[17:17] <sinzui> fab
[17:36] <henninge> sinzui: I requested a review (the branch had been previously reviewed) but I don't think the test would pass. Actually, I don't see how it passed for you after the changes in the template.
[17:36] <henninge> sinzui: I have to go home now, though. I will look into that tomorrow.
[17:37] <henninge> also, bin/test segfaults for me atm.
[17:39] <sinzui> henninge: make clean. make build; bin/test
[17:40] <henninge> sinzui: tried it, didn't help
[17:40] <henninge> sinzui: will try again tomorrow
[17:59] <jelmer> bigjools, al-maisan, noodles775: Is there a new Soyuz hacking room?
[18:01] <al-maisan> jelmer: we are on level 2, rooom waverly
[18:01] <al-maisan> *room
[18:01] <al-maisan> :P
[18:13] <maxb> gary_poster: ooh, great! Let me know when it happens and I'll patch up the stacked-on urls of the reassigned meta-lp-deps branches, and reassign my ~maxb branch for the ppa python-defaults over to the team
[19:16] <mwhudson> hello
[21:02] <mwhudson> make is bitching at me about PasteDeploy
[21:02] <mrevell> flacoste, ping
[21:02] <mwhudson> what does this mean again?
[21:02] <mwhudson> i know it's happened to me before
[21:07] <flacoste> hi mrevell
[21:08] <mrevell> hi flacoste
[21:12] <mrevell> hey, how can I help flacoste?
[21:13] <flacoste> hi mrevell: we'll be having 4 hours of codehosting downtime on Thu from 13:00UTC to 17:00UTC
[21:14] <mwhudson> we will?
[21:14]  * mwhudson hopes this is something to do with extremely large amounts of disk
[21:16]  * wgrant wonders why the reasonable notification period for extremely long downtime is not longer.
[21:18] <jml> wgrant, because we like to do things quickly
[21:18] <wgrant> jml: This is in conflict with having a reputation as a vaguely reliable hosting provider.
[21:18] <wgrant> Which is certainly not a reputation that you have now.
[21:25] <jml> gary_poster, hello
[21:26] <gary_poster> jml hi
[21:26] <jml> gary_poster, if I set up some casual contributors with a pre-2.5 Launchpad, how hard a time will they have updating their Launchpad?
[21:27] <gary_poster> jml, I don't think it will be too bad as long as they do a ``make clean`` before the ``make``
[21:27] <wgrant> That's all I had to do.
[21:27] <wgrant> They shouldn't run into the develop-eggs problem.
[21:27] <ajmitch> even that shouldn't be needed if the first thing they do is run rf-get?
[21:27] <jml> gary_poster, thanks.
[21:28] <gary_poster> jml, sure
[21:28] <cody-somerville> bigjools, I updated the branch with the changes bac requested.
[21:28] <bigjools> cody-somerville: you're sat 10 feet away from me
[21:29] <cody-somerville> bigjools, I didn't want to interrupt your conversation ;)
[21:29] <jelmer> rockstar, ping
[21:29] <cody-somerville> although its rather quiet at the moment
[21:29] <rockstar> jelmer, hi
[21:29] <wgrant> bigjools: Since the ec2 images apparently aren't 2.5-ready yet, do you have access to your monster of a home machine to test and land my branch?
[21:29] <gary_poster> wgrant: they should be ready
[21:29] <wgrant> sinzui: ^^
[21:29] <gary_poster> wgrant: did you encounter a problem?
[21:29] <bigjools> wgrant: I don't :(  I need to sort out wake-on-lan so I can turn it on remotely
[21:29] <jelmer> rockstar, you approved lp:~jelmer/launchpad-cscvs/converted-from earlier. Can I land that or do I need more reviews?
[21:30] <bigjools> wgrant: but I am sure someone like al-maisan will run it for you :)
[21:30] <jelmer> rockstar, (the merge proposal status is still needs-review)
[21:30] <rockstar> jelmer, if you can land it yourself, have at it.  I have it on my list of things to do to land it for you.
[21:30] <al-maisan> wgrant: what's the branch?
[21:31] <rockstar> jelmer, ah yes, I hate that status and vote are so disconnected.
[21:31] <wgrant> al-maisan: https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection-part1/+merge/14729 -- contrary to what the MP says, it's now targetted at db-devel.
[21:31] <wgrant> But LP doesn't appear to model that.
[21:31] <ajmitch> thumper: is https://blueprints.edge.launchpad.net/launchpad-code/+spec/branch-merge-bot similar to the idea from the other day that I talked to you about?
[21:32] <jelmer> rockstar: I'm not sure whether I have access, I'll give it a try
[21:32] <al-maisan> wgrant: could you please provide me with a submit message?
[21:33] <lifeless> intellectronica: the package is python-subunit
[21:33] <rockstar> jelmer, no harm in trying.
[21:33] <wgrant> al-maisan: Hm "Bits and pieces to prepare for Debian source format 3.0 support." is the only succinct way to put it.
[21:33] <al-maisan> wgrant: also, is there a bug open that this branch is fixing?
[21:33] <al-maisan> :)
[21:33] <wgrant> al-maisan: Not directly, no.
[21:33] <al-maisan> OK
[21:37] <jelmer> rockstar: looks like I indeed don't have access, I'll leave it up to you
[21:37] <rockstar> jelmer, okay.  I'll make sure to land it today.
[21:37] <jml> is there a package of lazr.restfulclient 0.9.10 anywhere?
[21:38] <wgrant> Oh, I see.
[21:38] <wgrant> (that Soyuz is back up to four now)
[21:39] <bigjools> \o/
[21:39] <wgrant> Very good.
[21:41] <thumper> ajmitch: on a call, talk to you soonish
[21:41] <ajmitch> np, it can wait :)
[21:41] <jml> python setup.py install on trunk lazr.restfulclient fails with error: Can't download http://bitworking.org/projects/httplib2/dist/httplib2-0.4.0.tar.gz: 404 Not Found
[22:04] <rockstar> ajmitch, I think that blueprint accurately describes Tarmac.
[22:04] <rockstar> :)
[22:05] <rockstar> (minus the branch merge queue stuff which doesn't currently exist in the UI)
[22:05] <ajmitch> rockstar: right, I was talking to thumper about the UI stuff to start with :)
[22:05] <ajmitch> then went & looked at existing blueprints
[22:07] <al-maisan> wgrant: your branch is running in ec2 now, if all goes well it should land in approx. 3.5 hours.
[22:08] <sinzui> EdwinGrubbs: bac: Last review period we closed 201 registry bugs. This period we closed 457.
[22:09] <wgrant> al-maisan: Thanks.
[22:09] <al-maisan> you are welcome
[22:09] <EdwinGrubbs> sinzui: how?
[22:10] <sinzui> Better cadence. The trivial policy closed 60 bugs.
[22:24] <jml> gah
[22:24] <jml> how do I run the tests in launchpadlib?
[22:26] <jml> given that https://bugs.edge.launchpad.net/launchpadlib/+bug/316694 is just adding a regex and a property, I'd like to patch it
[22:26] <mup> Bug #316694: Add web_link property to resources <launchpadlib :Triaged> <https://launchpad.net/bugs/316694>
[22:26]  * thumper is going make run with py2.5 for the first time
[22:26] <jml> but not being able to run the tests is a pain
[22:27] <thumper> jml: ask leonardr
[22:27] <jml> leonardr, ^
[22:30] <mwhudson> make is still breaking for me
[22:34] <mwhudson> man i want subscribe to tag
[22:35] <thumper> it works \o/
[22:35]  * thumper goes to merge devel into current work
[22:45] <mwhudson> ah, it works for me, after i make clean a bit harder
[22:46] <mwhudson> phew
[22:47] <leonardr> jml: you need to run the tests from within launchpad
[22:48] <leonardr> 1. check out a launchpad instance
[22:48] <leonardr> ln -s /path/to/dev/launchpadlib ./launchpadlib
[22:50] <jml> leonardr, ok thanks.
[22:52] <bigjools> jelmer: that bug you've picked is kinda hard actually
[22:52] <cody-somerville> bigjools, do retried builds get the manual bool set to true or something?
[22:52] <bigjools> cody-somerville: I don't remember off hand I'd need to look in the code
[22:54] <jml> leonardr, like this? jml@truth:~/src/launchpad/stable$ ln -s /home/jml/src/launchpadlib/trunk/ launchpadlib
[22:57] <leonardr> jml: sorry, i had to fry something
[22:57] <jml> leonardr, understood.
[22:57] <leonardr> yeah, whatever launchpadlib branch you've changed
[22:57] <leonardr> 3. change buildout.cfg from "." to "\t.\n\tlaunchpadlib"
[22:57] <leonardr> 4. run bin/buildout
[22:58] <leonardr> then run bin/test -vvt launchpadlib. you should see tests in your dev launchpadlib being run
[23:00] <jelmer> bigjools: so I'm finding out :-) I'll look for an easier one
[23:01] <bigjools> jelmer: yeah, it needs to join on all the PackageUpload* and use the right one :)
[23:02] <jml> leonardr, ok. thanks.
[23:03] <bigjools> jelmer: I think I already said, but anything marked trivial is a good start, but ask first because trivial is not necessarily an accurate tag for Soyuz :)
[23:04] <thumper> bigjools: I need to talk to you
[23:04] <thumper> bigjools: can you go skype somewhere?
[23:04] <bigjools> thumper: I can, gimme 2 mins
[23:04] <thumper> bigjools: ok
[23:04] <bigjools> thumper: or twinkle!
[23:05] <thumper> bigjools: I could twinkle
[23:05] <bigjools> I've no idea what my number is
[23:06] <jml> is this known? http://pastebin.ubuntu.com/321135/
[23:06]  * jml afk for a bit
[23:06] <bigjools> thumper: I am 7145
[23:07] <rockstar> I think I'll finish my current work before I try and merge 2.5 into it.
[23:07] <bigjools> thumper: dial meh
[23:08] <rockstar> Although I've taken about 2000 lines of js and have it condensed it down to about 600 lines of maintainable code.
[23:09] <leonardr> jml, i recently gave my father-in-law a book written by a guy named john lange in the 19th century
[23:14] <mwhudson> jelmer: hello
[23:14] <mwhudson> jelmer: what versions of subvertpy/bzr-svn should we use in launchpad?
[23:14] <mwhudson> (haven't researched this at all myself, so apologies if the answer is obvious)
[23:15] <thumper> bigjools: it tells me you are refusing my calls ;-)
[23:16] <bigjools> thumper: and it tells me you're not answering :)
[23:16] <bigjools> riiiiiiiing
[23:18] <cody-somerville> bigjools, I'm getting the impression that what happens is that retried builds simply don't get scored at all so are 0 by default.
[23:18] <bigjools> cody-somerville: correct!
[23:19] <jelmer> mwhudson: hi
[23:19] <mwhudson> jelmer: hello
[23:19] <jelmer> mwhudson: subvertpy 0.7.0 and the latest version of bzr-svn
[23:20] <mwhudson> jelmer: as in lp:bzr-svn tip?
[23:20] <jelmer> mwhudson: yeah, sorry - the latest revision
[23:20] <mwhudson> jelmer: ok thanks
[23:20] <jelmer> mwhudson: jszakmeister provided a fix that makes bzr-svn a bit friendlier to svn servers when retrieving logs
[23:21] <jelmer> mwhudson: that fix is not in any released versions yet
[23:21] <mwhudson> jelmer: ok
[23:21] <mwhudson> jelmer: will this version work with both bzr 2.0.0 and 2.1b3 ?
[23:22] <jelmer> yeah
[23:22] <mwhudson> thats what i wanted to hear, thanks :)
[23:23] <mwhudson> mwh@grond:trunk$ bzr push -r tag:subvertpy-0.7.0 ../subvertpy-0.7.0
[23:23] <mwhudson> Created new branch.
[23:23] <mwhudson> mwh@grond:trunk$ cd ../subvertpy-0.7.0
[23:23] <mwhudson> mwh@grond:subvertpy-0.7.0$ bzr push
[23:23] <mwhudson> bzr: ERROR: Working tree "/home/mwh/canonical/repos/subvertpy/subvertpy-0.7.0/" has uncommitted changes (See bzr status). Use --no-strict to force the push.
[23:23] <mwhudson> wtf!!
[23:24] <mwhudson> that really doesn't make any sense does it?
[23:24] <rockstar> mwhudson, you're sure that dir didn't exist before?
[23:25] <jelmer> mwhudson, it doesn't indeed - what changes are in that tree according to bzr st?
[23:25] <mwhudson> rockstar: the "created new branch" suggests not
[23:25] <mwhudson> jelmer: http://pastebin.ubuntu.com/321146/
[23:26] <rockstar> mwhudson, well, maybe it pushed a branch inside that dir.
[23:26] <rockstar> so you have ../subvertpy-0.7.0/trunk
[23:26] <mwhudson> rockstar: not this time
[23:27] <mwhudson> jelmer: it looks like the wt is the same as trunks?
[23:27]  * rockstar should not assume everyone is as silly as he is
[23:27] <mwhudson> yeah
[23:27] <mwhudson> rockstar: well, it was a reasonable theory
[23:28] <mwhudson> just not the right one this time :)
[23:28]  * jelmer is sure we're all missing something obvious here
[23:28] <jelmer> mwhudson: what version of bzr are you using?
[23:29] <mwhudson> jelmer: 2.1.0dev3
[23:29] <mwhudson> push -r 3 does even more odd things:
[23:29] <mwhudson> mwh@grond:trunk$ bzr push -r 3 ../r3
[23:29] <mwhudson> Path conflict: PLAN / PLAN
[23:29] <mwhudson> Path conflict: __init__.py / __init__.py
[23:29] <mwhudson> Path conflict: svnbranch.py / svnbranch.py
[23:29] <mwhudson> 3 conflicts encountered.
[23:29] <mwhudson> Created new branch.
[23:30] <mwhudson> (whatever is in ~bzr-daily-ppa or whatever it's called)
[23:31] <jelmer> mwhudson: that's really odd
[23:31] <jelmer> mwhudson: those are the files that existed in r1
[23:31] <mwhudson> let me try bzr tip i guess
[23:32]  * spm waves hi to jelmer while passing thru
[23:32] <mwhudson> it really seems like push -r $foo is behaving like push of tip and merge back to requested rev
[23:32] <mwhudson> no not tat
[23:33] <mwhudson> bzr tip does the same
[23:34] <mwhudson> let's try the 2.0 branch...
[23:35] <mwhudson> wtf, that's the same!!
[23:42] <cody-somerville> bigjools, how often does cronscripts/buildd-queue-builder.py run?
[23:43] <spm> cody-somerville: every 20 minutes; --score-only fwiw.
[23:44] <cody-somerville> bigjools, so retried builds don't stay scored at 0 for very long. Is that a bug or intentional?
[23:44] <bigjools> cody-somerville: intentional
[23:45] <bigjools> but tbh b-q-b makes no difference
[23:45] <jelmer> spm: hey
[23:45] <thumper> bbq?
[23:45] <bigjools> stfu mofo
[23:45] <thumper> mofo?
[23:45] <bigjools> bmx
[23:45] <cody-somerville> bigjools, what do you mean by it makes no difference?
[23:45] <thumper> wtf
[23:46] <spm> nfi
[23:46] <bigjools> cody-somerville: the rescoring makes no difference to the order that builds get done
[23:46] <wgrant> The time value component of the build score is tiny.
[23:46] <cody-somerville> bigjools, scores makes no difference to the order that builds get dispatched?
[23:47] <bigjools> cody-somerville: they do, but the auto-rescoring doesn't change the situation in practice
[23:47] <bigjools> because it's time-based
[23:49] <cody-somerville> it makes a huge difference because after the first run of b-q-b the queue record is scored as if it was normal
[23:50] <cody-somerville> so it only delays retried builds in any meaningful manner for no more than 20 minutes ever
[23:50] <bigjools> that should not happen
[23:51] <cody-somerville> then you haz a  bug
[23:51] <bigjools> yarp
[23:51]  * bigjools looks for powah