[00:32]  * mwhudson lunches
[01:01] <mwhudson> oh right
[01:01] <mwhudson> libapr-dev and libsvn-dev need to be installed *everywhere* or make build dies
[01:03] <mwhudson> er
[01:07] <wgrant> mwhudson: do you have access to import CAT packages into the ppa and ec2 images?
[01:07] <mwhudson> wgrant: um, maybe
[01:07] <mwhudson> wgrant: which images do you mean?
[01:07] <mwhudson> ec2 images that is
[01:08] <wgrant> both
[01:08] <maxb> CAT packages?
[01:08] <mwhudson> wgrant: i don't have access to the buildbot images
[01:09] <wgrant> not sure what it stands for, but it's the sysadmins' internal archive
[01:10] <wgrant> in other news, this onscreen keyboard sucks.
[01:10] <spm> it stands for notdog
[01:10] <mwhudson> wgrant: i think i can get the source package from inside the db and shove them into the ppa
[01:10] <mwhudson> but it might be better to ask someone who knows what they're doing
[01:12] <wgrant> well, i need the karmic->hardy dpkg backport everywhere in the next day or two
[01:12] <mwhudson> once it's in the ppa it's fairly easy to get it into the ec2 test images
[01:12] <wgrant> i have the diff, so could produce an identical package if required
[01:12] <wgrant> great
[01:12] <mwhudson> the buildbot images require a bunch of work
[01:13] <mwhudson> for the losas, not me
[01:13] <wgrant> ungreat
[01:13] <mwhudson> it's not hard, but it is time consuming
[01:13] <mwhudson> getting it onto the DC machines is very much not my problem
[01:13] <wgrant> right
[01:13] <mwhudson> but if it's in CAT already that shouldn't be too hard
[01:15] <spm> mwhudson: fwiw, despite my protestations otherwise - and they won't stop regardless of what I say next ;-) - updating the AMI's isn't that hard. It's fiddly and mindnumbing; but not hard. :-D
[01:15] <mwhudson> spm: that's what i was trying to say
[01:16] <spm> ha! great minds etc.
[03:46] <thumper> sometimes firefox's caching drives me up the freaking wall
[03:52]  * thumper wonders who reviewed the new comment js work
[03:54]  * thumper is frustrated it has no tests
[03:55] <thumper> the fix for the review replies on staging is deleting exactly one space
[03:55] <thumper> however
[03:55] <thumper> adding a tests sucks arse
[04:05] <wgrant> Does capitalisation count when sorting imports?
[04:17] <mwhudson> wgrant: case insensitive sort
[04:18] <wgrant> mwhudson: Thanks.
[04:20] <mwhudson> wgrant: do you know how published binaries get linked to the build that created them?
[04:22] <wgrant> mwhudson: buildd-manager gives process-upload.py the build ID.
[04:22] <mwhudson> wgrant: ah ok
[04:24] <mwhudson> i guess that'll be easy enough to mimic for building source packages from recipes
[04:25] <wgrant> Something could be easily enough arranged, I'm sure.
[04:45] <thumper> wgrant: I'll give you a chocolate fish if you rename SourcePackage to DistroSeriesSourcePackage :)
[04:55] <wgrant> Mmmm. Chocolate fish.
[07:57]  * wgrant WTFs at the rather preemptive SourcePackageFileTypes.
[08:21] <adeuring> good morning
[09:11] <mrevell> Morning compadres.
[09:12] <noodles775> Hi mrevell !
[10:01] <wgrant> al-maisan: In r9913 you added two new imports (getFileType and SourcePackageFileType) to lp.soyuz.model.publishing. They seem to be unused, and conflict with one of my branches. Can I safely remove them?
[10:01] <al-maisan> wgrant: if they are unused, yes, feel free to remove them.
[10:02] <al-maisan> wgrant: sorry for creating problems
[10:02] <wgrant> al-maisan: Thanks
[10:28] <jml> good morning Launchpadders.
[10:29] <al-maisan> Good morning jml
[10:40] <ajmitch> hi jml
[10:46] <jml> ajmitch, al-maisan: hello
[10:47] <jml> mwhudson, are you around?
[10:54] <lifeless> jml: 11:45pm there
[10:54] <lifeless> jml: signs point to no.
=== salgado-afk is now known as salgado
[11:12] <jml> xchat is being incorrect.
[11:39] <intellectronica> jml: dog bite man
=== matsubara-afk is now known as matsubara
[11:52] <jml> intellectronica, heh
[12:05] <al-maisan> hello wgrant, just going through https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
[12:06] <al-maisan> the "gpg --keyserver keyserver.launchpad.dev --send-keys <keyid>" part fails
[12:06]  * wgrant fixes a bug in it.
[12:06] <wgrant> Did you create /var/tmp/zeca?
[12:06] <wgrant> If you didn't, you'll get a 500.
[12:06] <al-maisan> ah, I missed that!
[12:06] <al-maisan> wgrant: thanks !
[12:07] <al-maisan> wgrant: that was the issue, after creating /var/tmp/zeca everything works
[12:07] <wgrant> al-maisan: Great.
[12:09] <jml> so much stuff.
[12:11]  * wgrant should get some of those changes merged at some point.
[12:42] <wgrant> al-maisan: No other issues so far?
=== mrevell is now known as mrevell-lunch
[12:48] <al-maisan> wgrant: I got entangled in postfix issues but that's unrelated to your instructions page
[12:56] <bac> hi jml.  just looking at your cookbook.  nice idea
[12:56] <jml> bac, it's Marjo's idea.
[12:56] <jml> I'm just the postman.
[12:57] <bac> jml:  your example can be simplified to login_with('hello-world', 'production')
[12:57] <bac> jml: or did you really want to show the other params in use
[12:57] <jml> bac, oh. cool.
[12:58] <jml> bac, umm, I don't so. Could you please update the example?
[12:58] <bac> jml:  sure
=== salgado_ is now known as salgado
[13:00] <jml> bac, thanks.
[13:01] <bac> deleting code is easy
[13:02] <jml> and fun!
[13:09] <al-maisan> wgrant: I have a new LP user with a PPA, moving on to the "Configure a buildd" section..
[13:26] <jtv> henninge: want me to write up how to test the storm fix?
[13:27] <sinzui> mthaddon: can is be an admin on staging to test
[13:27] <mthaddon> sinzui: can is?
[13:28] <sinzui> mthaddon: sorry, I have not had coffee yet
[13:28] <mthaddon> sinzui: what's your LP username?
[13:28] <sinzui> mthaddon: May I be an admin on staging so that I can test
[13:28] <sinzui> sinzui
[13:28] <maxb> Twisted egg! Woot!  However, sourcecode/Makefile and utilities/sourcedeps.conf haven't been updated
[13:29] <mthaddon> sinzui: done
=== mrevell-lunch is now known as mrevell
=== danilos-out is now known as danilos
[14:20] <flacoste> morning launchpadders
[14:21]  * bigjools waves at flacoste
[14:21]  * flacoste waves back
[14:31] <adiroiban> hi. I'm having some problems with pagetests/stories http://paste.ubuntu.com/327670/
[14:31]  * jml off to get some lunch
[14:31] <adiroiban> i tried to follow in information from https://dev.launchpad.net/Debugging but with no luck
[14:32] <intellectronica> adiroiban: this style of pagetest is particularly annoying to debug, since one failure trips the entire test and you get a lot of output which you can't really work with
[14:33] <adiroiban> still I need to write the test and pass it
[14:33] <adiroiban> in the devel branch everthing is ok
[14:33] <adiroiban> and i have just added a new column
[14:33] <adiroiban> but don't know how to modify the pagetest
[14:34] <intellectronica> adiroiban: right, so you've added a new column to the table, but not in the test?
[14:34] <adiroiban> I have added in the test
[14:34] <salgado> adiroiban, the existing page test expects to find a  'Last Update' in the text but it finds a 'Last update' instead
[14:35] <salgado> as intellectronica pointed out, these failures are really painful to debug
[14:35] <adiroiban> uh... stupid me
[14:35] <adiroiban> the diff was not very useful
[14:36] <adiroiban> I thought the fortmating in wrong
[14:36] <adiroiban> as each cell was on each line
[14:36] <adiroiban> instead of being alligned
[14:41] <salgado> adiroiban, that doesn't happen because our tests run with +NORMALIZE_WHITESPACE
[14:42] <salgado> I mean, the formatting in the expected output doesn't have to match that of the given one
[14:42] <adiroiban> this is my first attempt to fix a bug in LP
[14:43] <adiroiban> this is  why I'm just lost :)
[14:43] <adiroiban> is there a way to improve the way that diff was displayed ?
[14:44] <adiroiban> https://dev.launchpad.net/Debugging#Debugging stories/pagetests as it was not very useful for me
[14:45] <intellectronica> adiroiban: you could try to parse the table with beautiful soup and reformat it for printing line-by-line, so that at least if there's an error you get to see on which line it is
[14:45] <salgado> adiroiban, there's a --ndiff option you can pass to bin/test.  that might help
[14:46] <flacoste> gary_poster: did you see the good news, mwhudson updated to twisted 9 and as an egg!
=== gary_poster is now known as gary-call
[14:47] <intellectronica> salgado: what does --ndiff do?
[14:47] <salgado> intellectronica, not sure; never tried it
[14:48] <salgado> I just remember somebody mentioned it as useful in these cases
=== gary-call is now known as gary_poster
[14:50] <gary_poster> flacoste: wow, awesome!  no, I didn't.  I think that will allow a number of cleanups.
[14:53] <adiroiban> salgado: same result with --ndiff
[14:54] <adiroiban> will try with udiff and cdiff
[15:02] <bac> barry: are we having a reviewers meeting?
[15:02] <barry> bac: we should, but i'm otp
[15:02] <intellectronica> adiroiban: i don't think there's any diff that can help. the problem is that the output really is like what you see when the test fails. the fancy formatting in the document itself relies on doctests treating all whitespace equally
=== salgado is now known as salgado-lunch
=== matsubara is now known as matsubara-lunch
[15:24] <henninge> jtv: yes, please
[15:28] <barry> reviewers, developers, lurkers: apologies for the delay, i had some last minute phone calls.  i'd like to do the reviewers meeting in 5m.  i think it will be short -> #launchpad-meeting
[15:32] <barry> reviewers -> #launchpad-meeting in 2m
[15:34] <barry> reviewers -> #launchpad-meeting
[15:57] <allenap> sinzui: flacoste has approved https://code.edge.launchpad.net/~sinzui/launchpad/parent-packaging-links-bug-484828/+merge/15092 but there's an outstanding review request for ~launchpad. Is that correct? If so, I'll do it now.
[15:58] <sinzui> No it does not need review
[15:58] <flacoste> allenap: i think that's a bug in the code review system
[15:59] <allenap> sinzui, flacoste: Cool, thanks.
[15:59] <sinzui> allenap: I will delete it. The script was run once and it will not be merged
[16:01] <allenap> leonardr: There are a couple of quite old lazr branches of yours still showing as needing review: https://code.edge.launchpad.net/~leonardr/lazr.restfulclient/option-introspection/+merge/5800 and https://code.edge.launchpad.net/~leonardr/lazr.restful/service-request-to-web-request/+merge/7027
[16:02] <allenap> leonardr: Actually, one of them has been approved.
[16:02] <allenap> leonardr: Do they still need reviewing, or can they be marked as approved, or merged?
=== salgado-lunch is now known as salgado
[16:09] <jml> beuno, can we have a call in a little while?
[16:10] <beuno> jml, sure, although I'm about to step away for 30' of lunch
[16:10] <jml> beuno, after lunch is fine
[16:24] <gmb> jml, allenap: Either of you got any idea why ec2 land would say "running tests," give me the submit message bit and then shut down all on its own?
[16:25] <jml> gmb, is that really the full output?
[16:25] <mrevell> gmb, I can't answer you but I have seen that before.
[16:25] <gmb> jml: No. I should have said "get as far as saying "running tests"". https://pastebin.canonical.com/25039/ is the full output.
[16:26] <gmb> Aha!
[16:26] <gmb> So it's not necessarily me being rubbish.
[16:26] <mrevell> gmb, That looks familiar. I have no idea why it happened. I think I tried again and all was well. I hope that this greatly detailed reply will be of help.
[16:27] <gmb> Heh.
[16:27] <jml> gmb, no, I don't know.
[16:27] <gmb> This is the fifth or sixth attempt at landing this bloody thing... I'll keep trying.
[16:27] <jml> gmb, my hunch is that something is failing on the server side, and another bug is preventing it from being reported properly
[16:27] <gmb> jml: Okay, no worries. I'll see if I can work it out, or at least just get it to actually play.
[16:27] <jml> gmb, try using ec2 land to get the ec2 test command, then invoking ec2 test directly
[16:27] <gmb> jml: Right, that was going to be the next thing I did :)
=== matsubara-lunch is now known as matsubara
[16:30] <jtv> henninge: hi, I wasn't really EOD, just not paying attention
[16:31] <henninge> jtv: is this the right call: http://paste.ubuntu.com/327794/
[16:31] <henninge> ?
[16:32] <gmb> It's amazing how quickly you forget how to format a PQM message.
[16:32] <jml> yes :)
[16:32] <jtv> henninge: that looks right, yes—although creepy things happen with the gtk+2.0 package name in URLs.
[16:33] <henninge> gmb: [r=..][ui=..][bug=..]
[16:33] <henninge> jtv:  but that is not a url
[16:33] <jtv> right
[16:34] <jtv> henninge: what I mean is, there's a potential pitfall in the obvious way to get the package name.
[16:34] <jtv> it's close to midnight, don't be picky :)
[16:34] <jml> staging cronjobs are slow
[16:34] <henninge> jtv: np
[16:34] <henninge> jtv: how long did it usually run, what am I to expect?
[16:34] <henninge> ok, it never finished ....
[16:34] <jtv> henninge: hours.
[16:35] <henninge> jtv: so should I ask for staging updates to be stopped while it runs?
[16:35] <jtv> it'll still run for a long time (assuming all is well), but it'll no longer grow to 2.x GB of memory within the hour
[16:36] <henninge> jtv: oh, so if it does not do that, it can be stopped after an hour or so ?
[16:36] <jtv> right
[16:36] <jtv> just make sure it gets to at least stage 2; stage 3 if you can
[16:36] <henninge> I assume it says so in the output
[16:36] <jtv> yes, but there can be a lot of the stuff.
[16:37] <jtv> hang on, I'll look it up
[16:38] <henninge> jtv: I guess it can be tee'd.
[16:38] <jtv> I think you get log level "info" by default, right?  That prints "Removing duplicate messages" (start of stage 1), "Merging POTMsgSets" (start of stage 2), and "Merging TranslationMessages" (start of stage 3).
[16:38] <jtv> I would, yes, or nohup.
[16:38] <henninge> oh, it does detach?
[16:38] <jtv> not by itself, no
[16:38] <henninge> man nohup
[16:38] <jtv> nohup does two things:
[16:39] <jtv> 1. make the command not die on HUP
[16:39] <jtv> 2. write stdout & stderr to a log file, nohup.out
=== beuno is now known as beuno-lunch
[16:39] <jtv> If you combine it with &, you get a background process that doesn't die when your ssh connection does
[16:39] <henninge> I had thought it was for keeping jobs from detaching.
[16:39] <jtv> no, it's usually used in combination with detaching
[16:40] <jtv> $ nohup run_my_process.py &
[16:40] <jtv> [12345]
[16:40] <jtv> $ tail -f nohup.out
[16:40] <henninge> ah, that was my ascociation then
[16:40] <henninge> jtv: thanks, I'll let you EOD now ... ;-)
[16:40] <jtv> In stage 2, you'll see messages like "Message 10/254: 5 subordinate(s)."
[16:41] <henninge> jtv: what about them?
[16:41] <jtv> That's one way of seeing where you are despite tons of output.
[16:41] <henninge> ah!
[16:41] <jtv> I'd try a smaller package first though, and work your way up.
[16:42] <henninge> jtv: which is a smaller package, for example?
[16:43] <henninge> size is measured by number of strings, I guess
[16:43] <jtv> pretty much... of course how long it's been in main also matters
[16:43] <jtv> argh my wrists hurt
[16:44] <jtv> I'm looking for something small
[16:44] <henninge> jtv: I think I got it all. Rest your wrist (and your eyes and your head)
[16:44] <henninge> jtv: no, I can do that myself
[16:44] <jtv> thanks
[16:45] <henninge> jtv: I have to go afk for a little now. Have a good night!
[16:45] <jtv> thanks!
[16:45] <jtv> you too, good luck
[16:57] <sinzui> EdwinGrubbs: I was able to restore the milestone table to as it was before you changed it. I added a test to verify it. The page is was still broken because the tbody's children is not null instead of an empty list. We have a test for this but it does not run
[16:58] <sinzui> EdwinGrubbs: javascript/test/test_milestone_table will not play in my browser because YUI is undefined
=== jamalta is now known as jamalta|bot
=== jamalta|bot is now known as jamalta
=== beuno-lunch is now known as beuno
[17:04] <EdwinGrubbs> sinzui: I don't remember changing that. You should check that the path for the <script> tag in javascript/registry/tests/milestone_table.html actually points at the current location of yui.
[17:06] <sinzui> EdwinGrubbs: you made the table conditional in your bug-435260-duplicate-links branch. That is not important since the fix took a few minutes. I am more concerned that the JS did need a change and that we had a test for the function
[17:07] <sinzui> EdwinGrubbs: icing/yui/current no longer exists
[17:08] <sinzui> I have run make build of course
[17:08] <sinzui> is there something else I need to run?
[17:08] <EdwinGrubbs> sinzui: are you branched off of db-devel or devel?
[17:08] <sinzui> EdwinGrubbs: devel
[17:12] <EdwinGrubbs> sinzui: I'm cleaning and rebuilding to see if I get the same problem.
[17:13] <sinzui> I build db-devel just now. icing/yui/current does not exist
[17:13] <sinzui> oh!
[17:14] <sinzui> EdwinGrubbs: I see this in the log in db-devel:
[17:14] <sinzui> utilities/shhh.py bin/jsbuild  -b lazr-js/build -x testing/
[17:14] <sinzui> The found YUI root isn't valid: /home/curtis/Work/launchpad/db-devel/lib/canonical/launchpad/icing/yui/current/build
[17:20] <sinzui> EdwinGrubbs: I can manually make the 'current' symlink, The test shows the _prepend_node fails function  and that my fix does pass.
[17:26] <leonardr> allenap, one is merged, one is dead
[17:27] <allenap> leonardr: Cool. I marked the merged one as merged already (I eventually realised I should look at the branch page to check), and added a comment to the other.
[17:27] <leonardr> allenap: i marked the other one as rejected
[17:28] <allenap> leonardr: Great.
=== henninge_ is now known as henninge
[17:40] <sinzui> BjornT: EdwinGrubbs: Do you know if anyone has tried to write a wrapper for YUI.Test so that those tests (which rock) are automatically tested?
[17:44] <EdwinGrubbs> sinzui: I'm surprised by the error you got with jsbuild on db-devel. It created the yui/current/build directory structure correctly for me. BTW, it appears that for yui 3.0.0 that YUI().use('yuitest') needs to be changed to YUI().use('test')
[17:46] <sinzui> EdwinGrubbs: I see 3.0.0pr2 in db-devel not 3.0
[17:47] <sinzui> I think something else is wrong
[17:49] <EdwinGrubbs> sinzui: does your symlink in db-devel point to this version of lazr_js?  lazr-js/build/yui -> /home/egrubbs/canonical/lp-sourcedeps/eggs/lazr_js-0.9dev_r153-py2.5.egg/lazrjs/yui/
[17:51] <sinzui> no
[17:51] <sinzui> It points to lazr-js/build/yui
[17:51] <sinzui> EdwinGrubbs: do I make clean or just blow the link away
[17:52] <sinzui> I am very frustrated with this. I have a great test. It showed there was an error, but it does not run anymore
[17:52] <EdwinGrubbs> sinzui: no, the second symlink. lib/canonical/launchpad/icing/yui points to lazr-js/build/yui which itself is a symlink to the lazr-js egg.
[17:54] <sinzui> WTF, the link ti to a py2,4
[17:54] <sinzui> I removed py2.4 on my test machine. maybe I should remove it from this one
[18:04] <mrevell> night all
[18:55] <mwhudson> jml: hello
[18:55] <jml> mwhudson, hi
[18:55] <jml> mwhudson, would you be up for a skype call?
[18:56] <mwhudson> jml: my coffee is still brewing; after it's made sure
[18:56] <jml> mwhudson, cool.
[18:57] <mwhudson> jml: in the mean time, you could ready my first mail to the "Immediate plan for Build Farm generic jobs" thread
[18:57] <mwhudson> jml: that might explain what SourcePackageRecipeBranch is for
[18:57] <jml> ok. :)
[19:17] <mwhudson> jml: ok ready now
=== salgado is now known as salgado-afk
=== matsubara is now known as matsubara-afk
[20:58] <wgrant_> Is bigjools still in Texas?
=== wgrant_ is now known as wgrant
[21:16] <adiroiban1> hi, is there a way for creating pagetests based on regex?
[21:17] <adiroiban1> when testing a table
[21:27] <lifeless> adiroiban1: no
[21:27] <lifeless> adiroiban1: pagetests can do pattern matching with ...
[21:28] <lifeless> or you can manually use a regex and check that it matches, but thats ugly and hard to debug (which is a major limit of doctests)
[21:53] <lifeless> sinzui: ping
[21:53] <gary_poster> fwiw, cases like tables is what manuel addresses.  FIT tables are one of his examples.  I hope to bring that in to Launchpad sometime.
[21:53] <sinzui> Hi lifeless
[21:53] <gary_poster> s/is/are/
[21:53] <lifeless> sinzui: I'm concerned we're speaking past each other on the bug about contact addresses for teams.
[21:53] <lifeless> sinzui: I'm wondering if you have time for a brief chat (here is fine) about it.
[21:53] <sinzui> okay
[21:55] <lifeless> As a project owner, I need to create a number of 'noise' teams.
[21:55] <lifeless> teams to control commit and bug triage for instance.
[21:55] <lifeless> these are not distinct communities
[21:56] <lifeless> secondly, the default 'contact this team' feature in launchpad is really really really annoying, because it direct mails all the members, and noone can tell if someone replies.
[21:56] <lifeless> I should add another really there.
[21:56] <lifeless> So, what I want is for 'contact this team', on the 'noise' teams, to send mail to the main dev list.
[21:57] <thumper> beuno: ping
[21:57] <thumper> flacoste: confirmation for LCA miniconf has come through
[21:57] <flacoste> thumper: awesome!
[21:57] <lifeless> Now, I can setup a mail alias on my home mail server that will forward back to launchpad at the main dev list if launchpad won't permit what I want; but I don't think what I want is that unusual.
[21:58] <lifeless> sinzui: does this make sense?
[21:58] <beuno> thumper, pong
[21:58] <sinzui> lifeless: it does. I know teams are doing this now
[21:58] <lifeless> sinzui: alternatively/better would be for 'contact this team' to not exist for the housekeeping teams.
[21:58] <thumper> beuno: I think I have been convinced to show the review fields all the time
[21:58] <thumper> beuno: but instead of showing " - Select - " as the default
[21:59] <thumper> beuno: have something like "Just comment"
[21:59] <sinzui> lifeless: I think we should fix launchpad so that there are no housekeeping teams
[21:59] <wgrant> I think the problem here is actually that LP notifications are just too inflexible and really need to be completely rethough.
[21:59] <thumper> beuno: as we really want to suggest to people that they should give their opinion :)
[21:59] <beuno> thumper, that's crazy enough it could work
[21:59] <thumper> but don't have to
[21:59] <sinzui> lifeless: I think a team is for communication, and it should be clear who is involved in the communication
[21:59] <thumper> beuno: I'll mock it up
[22:00] <lifeless> sinzui: that would be nice too, though 'group of people who can commit' is obviously still a useful concept ;)
[22:00] <mwhudson> thumper: woo
[22:00] <sinzui> that is an ACL issue
[22:02] <sinzui> lifeless: My test for this issue is if had a patch that fixed all the insanity with teams and email addresses, and permitted an email address to be shared by many teams, I do not think I would accept it
[22:02] <lifeless> sinzui: Why not though?
[22:02] <lifeless> what does it do _for launchpad_ to require that uniqueness
[22:03] <sinzui> lifeless: because when launchpad tries to communicate with just that team, the message goes to the wrong people.
[22:03] <lifeless> sinzui: I disagree.
[22:03] <bac> hi nhandler
[22:03] <lifeless> if, as the owner of that email address (e.g. the list moderator) I assert that two different teams should be comunicated with at that address
[22:04] <nhandler> Hi bac
[22:04] <lifeless> then what doe it have to do with lp?
[22:04] <bac> nhandler: what happened with your branch?  did it fail in ec2?
[22:04] <nhandler> bac: No clue. I haven't gotten an email about it like I have in the past
[22:05] <bac> nhandler: hmm, i wonder if i messed it up?  i got no email either.  i'll try again now
[22:05] <sinzui> lifeless, that is essentially the same argument for why we accept a launchpad mailing list as a contact address even though we know no one is subscribed to it. I think that tis wrong.
[22:06] <lifeless> sinzui: can you describe how it is wrong?
[22:07] <sinzui> lifeless, The point that sways me to your side is that this is what really happens. I think we need a better solution to ensure the correct users are getting messages.
[22:07] <lifeless> sinzui: The thing I'm struggling with is that the limit seems arbitrary, and made by the sender, not the recipient. But if you consider business cards: I hand out *my address*, I don't ask the person I'm giving the card to for the address.
[22:08] <lifeless> sinzui: it sounds like one constraint/goal you have is 'when someone clicks Contact XXX in the web UI, you want to be sure that a mail was sent'
[22:08] <lifeless> sinzui: but you seem to be conflating it with 'when someone clicks Contact XXX in the web UI, you want to be sure that the message was received'
[22:08] <lifeless> sinzui: and these are very very diferent statements.
[22:09] <lifeless> For instance, contact me, on my home page - lp cannot tell that I received the email.
[22:09] <sinzui> lifeless: I am concerned about the ambiguity of responsabulity
[22:09] <lifeless> for a list with no subscribers, someone may be reading it on the web. Or via rss.
[22:10] <lifeless> sinzui: Please consider making that the problem of the folk who own the team & email address.
[22:10] <sinzui> lifeless: If I am a member of your list and can confirm an email address for my team, then I can co-opt it. I can even disable it for you when I disable it
[22:10] <lifeless> sinzui: the latter point sounds like a bug, not a must-have.
[22:11] <lifeless> sinzui: coopting is not possible without me knowing because I'll see the confirmation mail come through and be able to click on the 'cancel' link, or contact the sysadmins.
[22:11] <lifeless> sinzui: and if its a launchpad hosted list, you can require a list-team-admin to ack it directly in the UI.
[22:12] <sinzui> lifeless: I am not trying to be mean on this issue, even if I accepted it, I do not think it will be fixed in my lifetime given the complete and utter madness or accounts + email addresses + teams + ACL + mailing lists.
[22:12] <lifeless> sinzui: I appreciate that scheduling it may take forever :)
[22:13] <lifeless> but people work around this already, it seems more useful to me to have it acked as wishlist, and then (for instance) wgrant might fix it.
[22:13] <sinzui> lifeless: why are there multiple teams for a single address?
[22:13] <lifeless> sinzui: because discussion forums are not equivalent to teams.s
[22:14] <lifeless> sinzui: (I don't think you're being mean)
[22:16] <bac> nhandler: something odd is happening.  i resubmitted it and it seems to have terminated without running the tests.
[22:17] <wgrant> bac: gmb reported the same thing on launchpad-dev.
[22:17]  * bac looks
[22:22] <sinzui> lifeless: I am going to accept the bug purely on your point that users are working around this now. I think though that this may be a case there are other solutions to this problem. Launchpad does a poor job of dispatching emails to teams and their members. We have decided this issue cannot be solved, but I think it improving how we dispatch and who we dispatch to can be improved to make this issue moot.
[22:24] <lifeless> thanks:)
[22:27] <mwhudson> bac: it's probably my fault but i can't see how
[22:27]  * mwhudson decamps to a cafe for a change of seen back online in a few mins
[22:28] <bac> mwhudson: i just did two runs
[22:28] <bac> the first ended with: instance shutting-down
[22:29] <bac> the second with: instance running
[22:29] <bac> but both terminated immediately after detaching
[22:38] <bac> nhandler: i'm resubmitting using the work-around of not using --headless.  hopefully that'll work
[22:39] <nhandler> Thanks bac
[22:40] <sinzui> bac: I still have the test and submit command when I landed nhandler's last blueprint branch
[22:40] <bac> nhandler: please ping me if you don't get an email in 4-5 hours
[22:40] <bac> sinzui: i've hacked 'ec2 land' to not detach and will see if that works
[22:41] <bac> sinzui: it's not a matter of invoking it incorrectly.  the tool seems a bit broken.
[22:42] <sinzui> bac: this is the command I used: http://pastebin.ubuntu.com/328057/
[22:51] <wgrant> bigjools: When you have a moment, can you please have a look at my MP again?
[22:51] <bigjools> wgrant: doing it right now, nearly finished
[22:52] <wgrant> bigjools: Great. Thanks.
[22:52] <bigjools> wgrant: craploads better in some parts BTW
[22:54] <bac> sinzui: *when* it works, you can just do:  ec2 land <MP_URL>
[22:54] <sinzui> bac: emphasis on *when*
[22:55] <bac> sinzui: yes.  that's why i emphasized it.  :)
[22:55] <wgrant> bigjools: I thought so.
[22:55] <wgrant> I wish MPs had a ToC.
[22:56] <wgrant> The comments tend to be pretty massive.
[22:56] <bac> i wish MPs didn't hide the bug link so far down the page
[22:56] <bigjools> yeah, they need to be collapsable
[22:57] <bigjools> thumper, fix that will ya :)
[23:03] <bigjools> wgrant: ok done
[23:04] <bigjools> just a few more changes
[23:04] <bigjools> also, you didn't change the existing tests at all, do they still pass?
[23:04] <wgrant> bigjools: They still pass.
[23:04] <bigjools> ok cool
[23:05] <wgrant> bigjools: OK, fixing all those now. Thanks.
[23:08] <mwhudson> soyuz is eating my brain, again
[23:08] <bdrung> mwhudson: regarding bug 487897, when can we expect your suggested solution in the productive system (= when will i have a working bzr import to work with)? what's the release policy for the vcs importer?
[23:08] <mup> Bug #487897: VCS import from audacity CVS failed with invalid value for commit message <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/487897>
[23:09] <bigjools> mwhudson: may I assist with that^W^Wyou there?
[23:09] <wgrant> bigjools: Any hints for where to put the mixin?
[23:09] <bigjools> wgrant: I thought about that as soon as I hit send.  Eummmm....
[23:10] <bigjools> wgrant: lib/lp/soyuz/model/files.py I think
[23:10] <wgrant> bigjools: Ah, yes, that makes sense.
[23:10] <wgrant> Thanks.
[23:10] <bigjools> although archiveuploader shouldn't really import from there :/
[23:10] <bigjools> but that's the least of the problems with soyuz
[23:11] <wgrant> I don't see how (archive(uploader|publisher)|buildmaster) can possibly avoid using soyuz stuff.
[23:11] <bigjools> it actually does for the most part
[23:11] <bigjools> does avoid, I mean
[23:15] <wgrant> bigjools: I cannot think of a good name for this mixin either. SourceFileMixin, or something more specific?
[23:15] <bigjools> wgrant: that would be fine
[23:17] <wgrant> bigjools: I guess I should add explicit tests for the new property as well?
[23:18] <bigjools> wgrant: ideally yes but it's a mixin so don't worry too much
[23:18] <wgrant> bigjools: Ah, OK.
[23:20] <thumper> sinzui: ping
[23:20] <sinzui> Hi thumper
[23:21] <thumper> sinzui: can you explain to me why some pages have a <base> tag and some don't ?
[23:21] <sinzui> really?
[23:21] <thumper> yeah
[23:21] <thumper> I'm wanting to have a # anchor
[23:22] <thumper> but the base tag screws it up
[23:22] <thumper> and some pages don't have it, and some do
[23:22] <thumper> and I can't figure out why
[23:22] <sinzui> I do not know why pages want a base tag. It might help with some script urls, but I think we fixed the cross-domain issue a long time ago
[23:22] <thumper> sinzui: for example, a branch listing has a base tag, but the active code reviews doesn't
[23:23] <thumper> sinzui: and I can't work out how the active code reviews one didn't get one
[23:23] <sinzui> I think annotate might help explain the issue
[23:23] <thumper> sinzui: I'd explicitly like to have a page not have one
[23:23] <thumper> sinzui: they use the same base template...
[23:23] <sinzui> base-layout?
[23:25] <mwhudson> impressive, i moved from the cafe to the library and my connection to freenode stayed up
[23:25] <mwhudson> bigjools: possibly
[23:26] <mwhudson> bigjools: i'm looking at Build and wondering how many fields apply to building recipes into source packages
[23:26] <mwhudson> bigjools: and thinking "quite a lot of it, possibly"
[23:26] <thumper> sinzui: metal:use-macro="view/macro:page/main_only"
[23:26] <bigjools> mwhudson: I think I know where this is going as well.  You're scaring me.
[23:26] <thumper> mwhudson: how far is the cafe to the library?
[23:26] <mwhudson> bigjools: i don't, but it's scary too
[23:27] <mwhudson> thumper: not that far i guess, but my machine was asleep for at least a couple of minutes
[23:27] <thumper> mwhudson, bigjools: table inheritance fixes everything \o/
[23:27] <mwhudson> thumper: i'm not sure i believe you
[23:27] <bigjools> the bigger the inheritance the better, I say
[23:28] <thumper> mwhudson: heh
[23:28] <sinzui> thumper: that is base-layout, all pages use it...I am certain because I remove the old main-template Monday
[23:28] <bigjools> but old tables need to die first
[23:28] <thumper> sinzui: so why does one page have a <base> tag and the other not?
[23:29]  * sinzui looks
[23:30] <bigjools> mwhudson: so are you designing a RecipeBuild or similar?
[23:30] <mwhudson> bigjools: well, i've got as far as thinking we need one
[23:30] <bigjools> I coulda told you that :)
[23:30] <mwhudson> bigjools: well you did, but i also needed to see it for myself :-)
[23:30] <wgrant> bigjools: Note that this cannot land until the new dpkg-dev is in the various images.
[23:31] <sinzui> thumper: base-layout does not create a base tag. does one our the templates have a head_epilogue?
[23:31] <bigjools> wgrant: which images?
[23:31] <wgrant> bigjools: ec2test and buildbot AMIs.
[23:31] <thumper> nope
[23:31] <bigjools> mwhudson: yeah it links recipes to source packages, so it's kinda necessary
[23:31] <thumper> sinzui: ^^
[23:31] <mwhudson> bigjools: do you think it's better to have a RecipeBuild that has many similar fields to Build or do something different, like have RecipeBuild that points to a Build row?
[23:31] <mwhudson> bigjools: well, we could use the RecipeJob for that
[23:31] <bigjools> mwhudson: the former
[23:32] <mwhudson> (but i don't think we should)
[23:32] <mwhudson> bigjools: okay
[23:32] <bigjools> Build is for Source<->Binary package linkage
[23:32] <bigjools> best not confuse that
[23:32] <sinzui> thumper: there are no <base.* tags in the tree
[23:32] <thumper> :(
[23:32] <bigjools> mwhudson: yes you could also use RecipeJob, I think I mentioned that in an email, it depends on how much fluff you want in there etc.
[23:32] <mwhudson> bigjools: how is source binary pakage linkage done?
[23:33] <thumper> where the f*ck are they coming from then?
[23:33]  * sinzui looks at branch listing
[23:33] <thumper> sinzui: firefox maybe?
[23:33] <thumper> can't be
[23:33] <mwhudson> bigjools: i guess those scary *packagepublishinghistory tables are involved?
[23:33] <thumper> it doesn't know the underlying view name
[23:33] <bigjools> mwhudson: build has a sourcepackagerelease column, binarypackagerelease has a build column
[23:33] <thumper> it has to be created by us somewhere
[23:33] <bigjools> mwhudson: publication is orthogonal
[23:34] <mwhudson> bigjools: oh good
[23:34] <sinzui> thumper: YUI more likely. scripts can inject nodes
[23:34] <mwhudson> bigjools: what's a sourcepackagerelease again?
[23:34] <thumper> sinzui: no way
[23:34] <thumper> sinzui: it was there before yui
[23:34] <bigjools> mwhudson: build is the *how*, publishing is the *where*
[23:34] <mwhudson> bigjools: is it created during upload processing?
[23:34] <bigjools> mwhudson: yes, when a source package is uploaded
[23:35] <bigjools> uploading currently the only creation point of all source-related objects
[23:35] <sinzui> thumper, branch-index.pt has in invalid js element. It must have a close tag, it cannot be <empty />
[23:35] <mwhudson> bigjools: so this is jumping ahead a bit but if you wanted to link a binary to a recipe it would be
[23:36] <bigjools> mwhudson: I wouldn't do that
[23:36] <sinzui> thumper: that is a separate issue
[23:36] <thumper> sinzui: it isn't branch index
[23:36] <mwhudson> binarypackagerelease -> build -> sourcepackagerelease -> ??? -> recipe?
[23:36] <bigjools> oh indirectly
[23:36] <mwhudson> bigjools: i mean in the ui, sorry
[23:36] <thumper> sinzui: but lib/lp/code/templates/product-branches.pt
[23:36] <bigjools> yeah something like that
[23:36] <mwhudson> ok
[23:37] <mwhudson> i guess upload processing or something near that will have to change a bit to make the ??? part of that work
[23:38] <bigjools> mwhudson: well we'll be uploading the result of the recipe build - which is a source package - so we can do what we do for build uploads and tell process-upload which recipe generated it
[23:38] <bigjools> pretty trivial
[23:38] <mwhudson> bigjools: right
[23:39] <mwhudson> a column on sourcepackagerelease to sourcepackagerecipebuild would seem to fit the existing pattern
[23:39] <bigjools> if you look at process-upload it has a -b flag, this is only used by buildd-manager when it uploads binary packages
[23:39] <bigjools> mwhudson: I think the other way around
[23:39] <sinzui> thumper: I just tried epiphany for a sanity check. this is strange. <base> is being injected after the head element. It is not in out template rules. Maybe this is the rendering engine.
[23:40] <bigjools> sourcepackagerelease column on sourcepackagerecipebuild
[23:40] <thumper> sinzui: perhaps, maybe gary or some other zope person knows
[23:40] <thumper> sinzui: it is very frustrating
[23:40] <mwhudson> bigjools: oh right yes
[23:41] <sinzui> thumper: I am looking in web app. We have some rules there.
[23:41] <mwhudson> sinzui: i don't think it can be client-side; as thumper says how would it know the view name?
[23:41] <bigjools> mwhudson: if you can get to grips with the existing model then this becomes a little easier to visualise I think
[23:41] <sinzui> mwhudson: I agree
[23:41] <mwhudson> bigjools: no kidding
[23:41] <mwhudson> bigjools: i know it a lot better than i did two weeks ago! :)
[23:41] <bigjools> mwhudson: do you remember my database diagram that everyone laughed at at the epic? :)
[23:42] <mwhudson> bigjools: vaguely
[23:42] <bigjools> https://dev.launchpad.net/Soyuz/TechnicalDetails?action=AttachFile&rename=SoyuzBuilders.dia
[23:43] <bigjools> ah bollocks
[23:43] <bigjools> where's it gone
[23:43] <wgrant> Not copied from the old wiki?
[23:44] <bigjools> I uploaded my copy again
[23:44] <bigjools> now, how do I embed the png
[23:44] <sinzui> thumper: I think the template class (which has a __call__) is doing it
[23:45] <thumper> hmm
[23:45] <thumper> sinzui: so why on some and not on others?
[23:45] <sinzui> I do not know
[23:45] <mwhudson> bigjools: is it overly optimistic for me to ignore everything in the "publish" box?
[23:46] <wgrant> It's mostly wrong, so I would actively avoid reading it anyway.
[23:46] <bigjools> Oo
[23:46] <sinzui> thumper: I think this is zope
[23:46] <wgrant> Oh, no, that bit's actually right.
[23:47] <bigjools> it's all right
[23:47] <wgrant> Just years out of date.
[23:47] <bigjools> mwhudson: yes you can avoid that box
[23:47] <sinzui> thumper: and I think this has something to do with zcml registration
[23:48] <mwhudson> bigjools: yay
[23:49] <bigjools> right, I am getting attacked by insects.  And in Texas, everything is bigger.
[23:49]  * bigjools heads indoors
[23:49] <mwhudson> bigjools: sorry if i'm just being dense, but
[23:49] <mwhudson> <bigjools> mwhudson: I think the other way around
[23:49] <mwhudson> <bigjools> sourcepackagerelease column on sourcepackagerecipebuild
[23:49] <mwhudson> this doesn't seem like what happens currently
[23:49] <mwhudson> build has a link to what it's building (the spr)
[23:49] <bigjools> mwhudson: build has a sourcepackagerelease column
[23:49] <mwhudson> what's built (the bpr) links to build
[23:50] <mwhudson> so the analogy would be that the spr that's built would like to the recipebuild
[23:50] <mwhudson> s/like/link/
[23:51] <bigjools> mwhudson: true, but it would be a nullable FK in this case
[23:51] <mwhudson> bigjools: i guess in this case sourcepackagerelease <-> recipebuild is 1-1
[23:51] <mwhudson> bigjools: certainly!
[23:52] <mwhudson> i don't really have an opinion which way round is better, i guess
[23:52] <bigjools> hmmm
[23:52] <bigjools> yeah I guess I don't on reflection
[23:53] <bigjools> hmmm can't avoid the nullable FK either way
[23:53] <mwhudson> i think what's built linking to why it's built is a little more natural
[23:53] <mwhudson> bigjools: indeed
[23:53] <bigjools> agreede
[23:55] <mwhudson> ok cool
[23:55] <mwhudson> bigjools: did you see my email with a proposed db patch?
[23:55] <mwhudson> (i know you've had problems with that)
[23:56] <bigjools> mwhudson: still no email :/
[23:56] <mwhudson> bigjools: ok
[23:56] <bigjools> mwhudson: send it to bigjools@gmail.com and I can see it there
[23:56] <mwhudson> bigjools: i talked to jml and changed my mind on lots of things anyway :-)
[23:57] <bigjools> fook knows what's happened to my home server, I ordered a new PSU and UPS just in case!
[23:57] <mwhudson> bigjools: how much longer are you going to be around for today?
[23:58] <bigjools> mwhudson: not much
[23:58] <mwhudson> bigjools: ok
[23:58] <mwhudson> bigjools: i'll send an email with an updated patch later today, i guess you won't see it for some time
[23:58] <bigjools> I can hang around on here though
[23:58]  * mwhudson tries to summarize
[23:59] <bigjools> I won't be going out for an hour or so but I will need to scrub up a bit