[00:18] <thumper> no
[00:18]  * thumper is pretending to be buys
[00:18] <thumper> busy even
[00:20] <abentley> wgrant, SourcePackageRecipeBuildJob seems like it could be eliminated by putting a "job" column on "SourcePackageRecipeBuild"
[00:21] <wgrant> abentley: SPRBJ is gone in the new model: http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
[00:22] <abentley> wgrant, Where is Job?
[00:22] <wgrant> abentley: No longer involved in the build farm.
[00:23] <abentley> wgrant: please unify builds and jobs
[00:25] <wgrant> abentley: The current model is reasonably close to that...
[00:26] <abentley> By "current", you mean "without the changes shown in the diagram"?
[00:26] <wgrant> Right, the one that was implemented in Wellington.
[00:26] <wgrant> http://people.ubuntu.com/~wgrant/launchpad/buildfarm/current-build-model.png
[00:26] <wgrant> Why do you want Job involved?
[00:26] <wgrant> It's not awfully useful.
[00:28] <abentley> wgrant, I want common data to be represented in a common place in a consistent way, so that I can view it and address it by Job.id.
[00:31] <wgrant> I guess we could fairly simply replace some of BFJ's columns with delegations to Job.
[00:31] <wgrant> At least the other classes no longer have to care.
[00:33] <wgrant> Hm, so most of the columns in the job table aren't in IJob. Does that mean that they're not used anywhere, so Job looks less suitable than it actually is?
[00:35] <wgrant> abentley: What is a Job's lifetime?
[00:35] <wgrant> Does it persist after it completes?
[00:36] <abentley> wgrant, yes.
[00:37] <wgrant> Hrm hrm.
[00:37] <abentley> wgrant, what are the columns whose lack of exposure makes Job seem less suitable?
[00:37] <wgrant> Sounds like you need to argue with Soyuz.
[00:38] <wgrant> abentley: All that stuff like reason, next_report_due, scheduled_start, lease_expires, progress, attempt_count, max_retries...
[00:40] <abentley> wgrant, some of the columns you mention are exposed.  Others haven't been exposed yet due to YAGNI.
[00:40] <abentley> wgrant, if there's now a need, we could expose them.
[00:41] <wgrant> abentley: No, no, my point was that it makes it look more specific than it actually is.
[00:41] <wgrant> Their existence in the schema, that is.
[00:42] <abentley> wgrant, I see.
[00:45] <abentley> wgrant, So, reason, next_report_due, progress, attempt_count and max_retries are currently unused to my knowledge.
[00:45] <wgrant> abentley: attempt_count is actually used, but only internally.
[00:45] <abentley> wgrant, we record it, but I don't think we ever read it.
[00:45] <wgrant> abentley: Right.
[00:46] <abentley> scheduled_start is optional; if NULL, we attempt it as soon as we can.
[02:25] <thumper> wgrant: yeah, I agree with abentley that BuildFarmJob should defer many columns to Job
[02:25] <thumper> wgrant: and it should be a job type
[02:27] <thumper> also
[02:27] <thumper> it may well make sense to have a json_data blob on the BuildFarmJob table too for extra meta-data that is never queried against like the BranchJobs
[02:28] <thumper> it may make TranslationTemplateJob and SourcePackageRecipeJob as unnecessary
[02:31] <wgrant> thumper: Sounds like you need to talk to noodles/bigjools about this.
[02:31] <wgrant> None of that has been implemented yet, so it can be easily changed.
[02:31]  * thumper sighs
[03:02] <thumper> wgrant: how to we make the builders add ppa:dailydebs-team/bzr-builder to its sources?
[03:02] <thumper> wgrant: the second thing we'd need to do is to get an updated bzr-builder in that ppa
[03:49] <mwhudson> oh yay
[03:49] <mwhudson> ec2 test is completely broken
[04:38] <wgrant> thumper: Wellington discussion suggested that we would add an attribute to IDistribution specifying an extra archive to include for recipe builds.
[04:38] <wgrant> But it hasn't been discussed in three months.
[04:38] <wgrant> If so, that's really really easy to do -- we just need to make a decision.
[04:40] <thumper> wgrant: oh kay...
[04:40] <thumper> wgrant: feel free to reply to the email to remind everyone
[04:44] <wgrant> thumper: Replied.
[05:07] <wgrant> thumper: Did the copy of the email that went directly to you have more than just the list CC'd? I replied to all, and the other addresses were in the email that left my laptop... I'm wondering whether it was mailman or a braindead uni SMTP server that stripped the extra CC addresses.
[05:08] <thumper> wgrant: yes it did
[05:09] <wgrant> Why, then, does the copy on the list not... grr.
[05:10] <thumper> wgrant: because the list copy tries to determine if the people you sent it to are on the list
[05:11] <thumper> wgrant: it is a feature:)
[05:12] <wgrant> thumper: Ah, like the "feature" where it doesn't send me a copy through the list if I'm addressed directly?
[05:13] <thumper> something like hat
[05:13] <thumper> s/hat/that/
[05:48] <cody-somerville> Soyuz is acting up.
[05:48] <wgrant> cody-somerville: What's it doing?
[05:48] <wgrant> Or not doing?
[05:48] <mwhudson> cody-somerville: best to say "losa" when you say that?
[05:48] <mwhudson> or wgrant
[05:49] <cody-somerville> builds for multiple packages are getting rejected because it can't find the source package
[05:49] <spm> logs?
[05:50] <cody-somerville> oh wait, maybe the packages did get superseded but the error messages are very ugly.
[05:51] <wgrant> That error message is ugly, yes.
[05:51] <wgrant> But normal.
[05:51] <cody-somerville> ah, false alarm.
[05:52] <cody-somerville> Got jumpy because I got so many emails about it
[05:52] <spm> we did just have a glitch on apache/ppa due to a new cronjob that was ... um.... *badly* behaved. so possibly cause and effect there.
[05:53] <cody-somerville> Looks like just a sloppy engineer in this case
[05:53] <spm> heh
[05:54] <wgrant> spm: My new cronjob? :/
[05:55] <wgrant> Did it eat all of germanium's RAM for lunch, or something else?
[05:57] <spm> wgrant: if it's called parse-ppa-apache-access-logs.py ? yes.
[05:58] <spm> it was at 2.5Gb RSS when I had to kill it as it had caused apache to be swapped out
[05:59] <wgrant> Argh.
[05:59] <wgrant> Anyway, /me -> exam.
[05:59] <spm> anyone who says ram is cheap at this point, will get a smacked bottom. :-P
[05:59] <spm> good luck!
[06:04] <mwhudson> spm: is it cheaper than disk? :)
[06:05] <StevenK> spm: RAM *is* cheap ... to allocate
[06:16] <thumper> spm: I think RAM is cheap
[06:16] <thumper> spm: how much to you need?
[06:17] <spm> thumper: I think RAM is cheap, therefor I am RAM?
[06:17] <thumper> spm: WFM
[08:14] <adeuring> good morning
[08:21] <jtv> hi adeuring
[08:21] <adeuring> hi jtv!
[09:15] <mrevell> Hello
[09:19] <bigjools> wgrant: hello
[09:19] <bigjools> dunno if you spoke to spm but FYI, the log parsing script gobbled >2.5GB RSS so had to be stopped.
[09:35] <wgrant> bigjools: I saw that, yeah. I suppose the librarian one would do that too if it had a huge volume of logs too.
[09:38] <wgrant> Not sure what to do, unless we convince it to stop after some millions of lines.
[09:40] <wgrant> The comment in the librarian parser suggests store._cache.clear().
[09:40] <wgrant> But I doubt that's the problem here.
[09:40] <jml> good morning Launchpadders?
[09:52] <bigjools> wgrant: salgado said he'd fixed the issue so you might want to catch up with him
[09:52] <bigjools> wgrant: or you could copy the publisher process_in_batches stuff
[09:55] <wgrant> bigjools: It's either the dict getting fricking huge, or StupidCache being really stupid. I don't know which.
[09:55] <bigjools> yes
[09:57] <wgrant> bigjools: Do we have a traceback, or was it killed harder than that?
[09:59] <bigjools> wgrant: dunno, I didn't see one, I think they just killed it when it got big as apache was dying
[10:00] <wgrant> bigjools: Do you know how big the logs tend to be? I really have no idea what sort of size we're talking about here.
[10:00] <jml> james_w: which one of you should I be talking to?
[10:03] <bigjools> wgrant: otp right now, will check in a bit
[10:03] <jml> james_w``: hello?
[10:03] <wgrant> bigjools: OK, thanks.
[10:08] <james_w> hi jml
[10:23] <mrevell> intellectronica, Hi, got five minutes?
[10:23] <intellectronica> mrevell: sure
[10:24] <mrevell> Thanks intellectronica. I wanted to ask you about adding a pop-up help link to the bug heat flames, wherever they're displayed.
[10:24] <mrevell> intellectronica, I can dive in and take a look at the templates first, if you prefer.
[10:25] <intellectronica> mrevell: i thought we already discussed it yesterday? any difficulties?
[10:25] <intellectronica> i'm also happy to add the link myself if you prefer that
[10:27] <mrevell> intellectronica, Sorry, yeah, you directed me to the right place. If I make the change, could you take a look at my diff, please? It's my first change of this kind.
[10:28] <intellectronica> mrevell: of course
[10:29] <mrevell> Thanks intellectronica -- http://pastebin.ubuntu.com/420319/
[10:30] <intellectronica> mrevell: the code looks fine. does the result look ok?
[10:31] <mrevell> intellectronica, Thanks. An apt-get autoremove seems to have just wiped out launchpad-developer-dependencies; not sure why. Just reinstalling everything I need to make run :)
[10:32] <intellectronica> mrevell: whoops
[10:50] <jtv> wgrant: are the slave build cookies now _only_ checked when rescuing a lost builder?
[10:55] <wgrant> jtv: I believe so.
[10:56] <jtv> wgrant: any idea how we'd simulate verification for Q/A?
[10:58] <wgrant> jtv: You could get two builds running on dogfood, then swap the BQ.builder values in the DB.
[10:58] <jtv> wgrant: nasty
[10:58] <wgrant> Or you could possibly use a fake builder.
[11:03] <jtv> wgrant: sorry for the long silences; some big distractions going on.
[13:03] <deryck> intellectronica, hi.  The board suggests bug 567375 has been merged, but the MP doesn't.  Has it merged?
[13:03] <mup> Bug #567375: Degrade bug heat daily <story-bug-heat> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/567375>
[13:05] <intellectronica> deryck: i think it has. at least, i've got a success email, let me check.
[13:07] <intellectronica> deryck: damn, looks like it didn't, so something must have happened between EC2 and the submission. will merge now.
[13:09] <deryck> intellectronica, ok, cool.  Thanks
[13:09] <deryck> intellectronica, and then the bugs remaining would be the activity points idea and then garbo-daily to garbo-hourly, right?
[13:10] <intellectronica> deryck: yes, i've just submitted the last branch for review.
[13:10] <deryck> intellectronica, ah, nice!  Can you add cards to the board for these two?  Are am I just missing where they are?
[13:11] <intellectronica> deryck: sorry, no, i need to create them. let me just get that review going and that branch merged and i'll add them
[13:13] <deryck> intellectronica, ok, great thanks.  Sorry to throw so many at you.  Just house cleaning before being on leave tomorrow. :-)
[13:14] <intellectronica> no worries. should have really done that when creating the bugs. old dog etc'...
[14:20] <mars> mrevell, should the underline problem be visible on launchpad.dev Bug #1?
[14:21] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:Incomplete by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress
[14:21] <mars> argh
[14:21] <mrevell> mars, No. The underline shouldn't appear on any of the bug flame images.
[14:22] <mars> mrevell, ok, what page should I view to see the problem?
[14:23] <mrevell> mars, I'm sorry. I misunderstood. Yes, if you visit bug one on launchpad.dev you'll see the dotted underline on the flame icon.
[14:25] <wgrant> salgado: Did you have python-tdb installed when running the test suite?
[14:25] <wgrant> salgado: That causes those import errors.
[14:25] <wgrant> '#
[14:25] <wgrant> Do not have python-tdb installed, which otherwise causes bzr-hg and bzr-git to behave in ways the tests do not expect. '
[14:26] <salgado> wgrant, all I have is libtdb1
[14:27] <wgrant> salgado: Your sourcecode bzr-git is up to date?
[14:30] <salgado> crap, I missed that (and a few others) because I ran my hack to update sourcecode/ branches under lib/
[14:30] <salgado> wgrant, thanks for catching that; I'll update the wikipage
[14:31] <wgrant> AFAIK everything is now fixed apart from the valid_absolute_url thing.
[14:31] <wgrant> Although I didn't see the fix for the bugtracker failure.
[14:33] <wgrant> Ah, there.
[14:33] <wgrant> So, yes, apart from the valid_absolute_url issue it all looks good.
[14:33] <wgrant> Yay.
[14:34] <mars> mrevell, I do not see the underline on this branch.
[14:36] <mars> mrevell, just in my team standup call, and I have something high priority I need to switch to.  Perhaps someone else can help squish it?  sinzui and noodles775 are also good with CSS.
[14:37] <mrevell> Thanks for looking mars
[14:37] <mrevell> Do you have a moment noodles775?
[14:38] <mars> no problem, sorry I can't help more
[14:38] <noodles775> mrevell: sure, I'm just finishing off a CP-review. Say in 2 mins?
[14:38] <mrevell> noodles775, top of the hour okay for you? That's after my stand-up.
[14:40] <noodles775> mrevell: sure.
[14:41] <mrevell> thanks noodles775 :)
[15:05] <noodles775> mrevell: I'm guessing you've got uncommitted changes locally in your branch? I've merged it from LP, but it just adds the help file without linking the bug heat to it, afaics?
[15:09] <mrevell> noodles775, Oh, odd. I thought it had pushed, lemme check
[15:11] <mrevell> noodles775, I've just pushed a new version up
[15:11] <noodles775> Great, looking now...
[15:13] <noodles775> mrevell: and you want it just without the underline, is that right?
[15:13] <noodles775> (well, the dotted bottom border from a.help)
[15:14] <mrevell> noodles775, Yeah, no underline at all.
[15:14] <mrevell> noodles775, I tried playing with a style="text-decoration: none" on the <a> and the <img> but to no avail.
[15:15] <noodles775> mrevell: yeah, inspecting it (using the chromium debugger) shows that a.help is actually adding a bottom-border: 1px dotted...
[15:15] <noodles775> So you might have more luck with style="bottom-border..."
[15:15]  * noodles775 tries.
[15:15] <mrevell> Ahhh
[15:17] <noodles775> er, border-bottom ;)
[15:20] <noodles775> mrevell: yep, that works...http://pastebin.ubuntu.com/420447/
[15:21] <mrevell> noodles775, Thanks, just got it up here on my local instance too :) Cheers!
[15:21] <noodles775> Great.
[15:21] <mrevell> noodles775, Is that acceptable, adding an inline stlye like that?
[15:24] <noodles775> mrevell: From my point of view, if it is a complete exception for a help link to not have the normal style, then I would rather it here than in the stylesheet (sinzui might differ?). On the other hand, something general like a .no-border class could be reusable?
[15:24]  * noodles775 checks to see if something like that exists already.
[15:26] <sinzui> I think exceptional rules do no belong in a global stylesheet. I also question why we need exceptions since the user has no context for what the presentation meens
[15:26] <sinzui> means
[15:28] <mrevell> sinzui, I'm not sure what you mean by the user having no context for what the presentation means.
[15:30] <sinzui> mrevell, We know a green link is a js-action because it is used consistently in launchpad. If I have never seen a presentation style, I do not know what to expect.
[15:31] <noodles775> mrevell: why do you want the exception here? Is it just because the bug heat icon looks ugly with the underline? Or would images in general look ugly with an underline, in which case http://pastebin.ubuntu.com/420455/ would also work.
[15:32] <noodles775> s/images in general/images within a help text link in general/
[15:33] <mrevell> noodles775, When Deryck and I were discussing the implementation we were concerned that the underline would be overly distracting; the link is of secondary importance and not directly related to the purpose of the flames, so we felt too much attention shouldn't be drawn to their being a link.
[15:33] <sinzui> mrevell, , noodles775, right. No image should be underlined and we have rules for it. are the rules in the css bad, or is the markup bad
[15:33]  * mrevell looks at the pastebin
[15:33] <noodles775> sinzui is right in that you can't tell it's a help link without the underline until you then hover over it, but as you said, that's ok here.
[15:34] <noodles775> sinzui: it's a border-bottom that is used by a.help (see the previous paste).
[15:34] <mrevell> noodles775, Your suggestion in the pastebin would work very well, actually, as I wouldn't want the dotted underline on any pop-up help image.
[15:34] <noodles775> Great.
[15:35] <mrevell> noodles775, The only other time I can imagine using a help link on an image, and wanting people to be absolutely sure it was a help link, would be with a help icon, so that'd be fine without the underline as I think it's self-explanatory.
[15:35] <noodles775> Yep.
[15:37] <mrevell> Thanks noodles775, I'll apply that icing change and then pop it in for review.
[15:37] <noodles775> k.
[15:54] <noodles775> oh, mrevell, while you're at it, could you move those help links from style.css into style-3-0.css.in?
[15:54] <noodles775> s/help links/help styles/
[15:56] <mrevell> noodles775, sure
[16:00] <jml> leonardr: hi. I'll be with you in a bit.
[16:00] <leonardr> hi jml
[16:03] <jml> leonardr: which voice medium best suits you
[16:03] <leonardr> jml: i can do mumble or skype
[16:34] <henninge> danilos: hey, still around?
[16:38] <henninge> I have an approved branch that is a CP candidate.
[16:38] <danilos> henninge, yes
[16:39] <danilos> henninge, have you gotten approval from flacoste as well?
[16:39] <henninge> I did branch it off production-stable but now I don't know were to put it.
[16:39] <henninge> danilos: that's what I was wondering.
[16:39] <henninge> danilos: does it go directly into production-devel?
[16:39] <henninge> thinking about it ... yes, obviously
[16:40] <danilos> henninge, yeah, you should land it on production-devel once it's approved
[16:40] <danilos> henninge, have you ran the full test suite?
[16:40] <flacoste> henninge: and have you QA-ed it yet?
[16:40] <henninge> danilos: no, I was going to ec2 land it
[16:41] <danilos> henninge, if there was no full test run, it's not going to be ready for CP before 2200 UTC
[16:42] <henninge> danilos: I was not going to CP it yet, I was just asking for the procedure.
[16:42] <henninge> flacoste: so, to QA it I need to land it on (db-)devel first?
[16:43] <danilos> henninge, right, it might not make much sense to CP it if we can't make it in time for the language pack generation
[16:43] <flacoste> henninge: yes
[16:43] <danilos> henninge, there's always cowboying into staging
[16:43] <henninge> danilos: right, when does that start?
[16:43] <flacoste> that also
[16:44] <danilos> henninge, that starts at 2200 UTC, so I don't think we can make it in time (two full test runs will take ~8h, and CP to loganberry will take some time as well)
[16:45] <henninge> danilos: oh, I kind of forgot about that ... sorry
[16:45] <danilos> henninge, I'd suggest you land it in the regular way and I'll let dpm know about it so he can let Lithuanian translators know; he'll tell us when they plan to do next language pack update
[16:45] <danilos> henninge, we might not need to CP it anymore
[16:47] <henninge> danilos: could we not short-cut it if it's only loganberry?
[16:48] <danilos> henninge, how would we cut it short?
[16:48] <henninge> once it's passed ec2 and QA'ed on staging, cowboy it onto loganberry?
[16:48] <danilos> henninge, (in general, "no", but I am interested in your idea :)
[16:48] <henninge> danilos: just to save one ec2 run
[16:48] <danilos> henninge, huh, it's not that critical an issue
[16:48] <henninge> danilos: ok, then I am not that worried ... ;)
[16:49] <danilos> henninge, that would be possible if all hell was breaking loose and things are falling apart; otherwise, let's not even think about doing something like that :)
[17:18] <henninge> is it possible that ec2 is not working on a production branch atm?
[17:19] <henninge> I always get this on "ec2 test", right after the instance has started:
[17:19] <henninge> SFTPError: Garbage packet received
[17:19] <henninge> instance shutting-down
[17:21] <james_w> you'll get that if you are using an ec2 script from before the ec2test -> ubuntu user transition, but that's not necessarily the reason
[17:22] <henninge> james_w: possible, as I said, I have a branch based on production-stable.
[17:22] <henninge> but actually, tha is not necessary anymoew, might as well merge devel.
[17:22] <henninge> right, danilos? ^
[17:26]  * henninge gives up for today
[18:03] <mrevell> make run is complaining about something annoying, so I'm taking that as a hint to give in for now. See you tomorrow.
[18:20] <bac> adiroiban: finally(!) your branch has landed
[18:21] <adiroiban> bac: thanks :)
[18:21] <bac> adiroiban: np.  sorry it took so long.
[18:24] <adiroiban> bac: don't worry... from my point of view it was fast , and it was not a critical branch
[18:28] <maxb> salgado: hi, w.r.t. your valid_absolute_url change on the python2.6 branch - wgrant and I were leaving that unfixed as a reminder that the database constraint needed thought
[18:28] <maxb> What are your thoughts on this?
[18:29] <maxb> I think it is pretty horrible that "valid_absolute_url" includes some implicit filtering on schemes
[18:30] <salgado> maxb, what filtering?
[18:30] <maxb> The py2.5 behaviour of valid_absolute_url was to only succeed for registered netloc schemes
[18:31] <salgado> right, and the new one follows the rfc
[18:31] <maxb> I believe this may have been being (ab)used to constrain file:/// urls to not be entered in the DB
[18:31] <maxb> or something like that
[18:35] <salgado> maxb, I think we have more restrictive field validators to take care of that.  we *should* be doing that, at least
[18:36] <salgado> in the case of DistributionMirror.http_base_url & co, for instance, I'm sure we do
[18:38] <maxb> announcement.url branch.home_page_url branch.url builder.url distributionmirror.*_base_url productseries.releasefileglob specification.specurl codeimport.url
[18:38] <maxb> ^ fields using this validator
[18:38] <maxb> erm, constraint
[18:40] <salgado> right, I know which ones use that, but my point is that these fields should have the more restrictive validators that may not be trivial to write as DB constraints
[18:41] <salgado> they should not rely on DB constraints doing their work.  if they do, they're broken
[18:50] <NCommander> anyone around who can help me figure out how to talk to the LP database properly? I'm having issues writing a converter script for changelogs, and I'm scratching my head on why I'm getting None as a result
[18:54] <salgado> maxb, I just realized it may not be clear what I meant above.  I was talking about field validators like what you get by using URIField
[18:55] <salgado> valid_absolute_url is just a safety net; we can't rely on DB constraints for our input validation
[21:05] <salgado> sinzui, is it known that on https://edge.launchpad.net/udd the page scrolls down to the bottom right after loading?
[21:05] <sinzui> salgado, I have observed that. It is because of the Packages in Ubuntu portlet
[21:06] <salgado> yep
[21:06] <salgado> sinzui, want a bug for it or is there one already?
[21:06] <salgado> or c) none of the above? ;)
[21:06] <sinzui> No, I suspect javascript may be in play
[21:07] <sinzui> salgado, I usually fix the issue by selecting a package. I am waiting for a db review to land the option that lets users say the project is not packaged,
[21:09] <salgado> sinzui, oh, ok, cool
[21:09] <sinzui> salgado, while this is annoying behaviour, it has encouraged me to link more that 50 packages in the last month
[21:10] <salgado> sinzui, yeah, I see the value in it too.  I'd do the same if this project were packaged
[21:11] <sinzui> yes. my projects are not in ubuntu. I really want to land my fix
[21:27] <sinzui> salgado, I think the portlet problem is cause by the setFocusByName() call. I think we can disable that. did you report a bug?
[21:28] <salgado> sinzui, nope.  want me to?
[21:28] <sinzui> salgado, I'll do it now
[21:28] <sinzui> bac: do you want me to restart the lp builder that lost the slave
[22:10] <wgrant> flacoste: Regarding the bzr-builder thing: the builders are virtualized and we run arbitrary user code on them.
[22:11] <wgrant> Does the IS-controlled archive restricton still apply?
[22:11] <flacoste> wgrant: it seems so, i've asked IS
[22:12] <wgrant> Well, we can't just install it on the builder.
[22:12] <wgrant> We need an archive somewhere.
[22:12] <wgrant> I guess we could have an IS-controlled PPA.
[22:12] <wgrant> But it seems utterly pointless.
[22:13] <flacoste> wgrant: we do have non virtualized builders btw
[22:13] <wgrant> flacoste: Not for recipe builds.
[22:14] <wgrant> They explicitly run only on virtual builders.
[22:14] <flacoste> for the time being
[22:14] <flacoste> and i don't know how much of the buildd infrastructure is shared between virtualised and non-virtualised build
[22:14] <flacoste> and the point still stand: we do run arbitrary user code on all of the builders
[22:14] <flacoste> virtualised or not
[22:15] <wgrant> Except that the non-virt ones are only used by Canonicalers, but yes.
[22:15] <flacoste> hmm, as far as i know, universe bulds will also use the non-virtualised ones
[22:16] <flacoste> which mean that MOTUs builds aren't virtualised
[22:16] <flacoste> at lest on some architectures
[22:16] <wgrant> Well, yes, Canonical and trusted Ubuntu people.
[22:16] <wgrant> But not randoms.
[22:20] <persia> Note that there are plenty of core-devs that aren't Canonical, and plenty of Canonical folks who aren't core-dev.  main/universe is not useful in this context.
[22:55] <mwhudson> gary_poster: hey
[22:55] <gary_poster> hey mwhudson
[22:55] <mwhudson> gary_poster: is there a way to say "don't security proxy instances of this class" ?
[22:55] <mwhudson> gary_poster: for context
[22:56] <gary_poster> mwhudson, yes
[22:56] <mwhudson> gary_poster: awesome, you can probably guess my next question
[22:56] <gary_poster> mwhudson, look at bottom of zope/security/checkers.py...will see if I see the pertinent bits quickly
[22:56] <mwhudson> i'm adding IBranch['getBzrBranch'] and don't want the bzrlib.branch.Branch to get wrapped
[22:57] <gary_poster> mwhudson: ...ever?  Usually the mechanism is for things that can't be mutated by naughty code
[22:57] <gary_poster> like strings
[22:57] <mwhudson> gary_poster: well
[22:57] <mwhudson> probably yes
[22:58] <gary_poster> ok :-)
[22:58] <mwhudson> 'real' mutations to branches are disk operations and they are defended against by other mechanisms
[22:58] <gary_poster> ah, I see
[22:59] <mwhudson> basically, i don't want to write zcml for all the eleventy million bzr classes and their attributes
[23:02] <gary_poster> mwhudson, not sure it is what you want, but BasicTypes?  See _basic_types, beneath it.  You could use zope.security.BasicTypes.update with a dict of {your_class_here: zope.security.NoProxy}
[23:02] <gary_poster> you could do that in lp_sitecustomize.py
[23:02] <mwhudson> gary_poster: ok, let me try that
[23:02] <gary_poster> ok
[23:07] <mwhudson> gary_poster: doesn't seem to have had an effect
[23:07] <mwhudson> gary_poster: here's what i tried http://pastebin.ubuntu.com/420696/
[23:09] <gary_poster> mwhudson: hm. a bit surprising and disappointing.  Is that the entire diff--that is, if I apply the patch I should be able to dupe?
[23:10] <mwhudson> gary_poster: um, this is on the end of a very long pipe :)
[23:10] <gary_poster> I thought it might be :-)
[23:10] <gary_poster> um
[23:10] <mwhudson> gary_poster: i should be able to cook up a diff you can apply
[23:12] <gary_poster> mwhudson: ok cool.  I have to go really soon, but I'll try to hang on
[23:13] <mwhudson> gary_poster: http://en.wikipedia.org/wiki/Bunny_hopping
[23:13] <mwhudson> haha
[23:13] <mwhudson> gary_poster: http://pastebin.ubuntu.com/420699/ <- this one :)
[23:13] <mwhudson> stupid firefox
[23:13] <gary_poster> lol
[23:15] <mwhudson> gary_poster: i think i want zope.security.defineChecker ?
[23:15] <gary_poster> that does sound more familiar.  This part of the machinery is just a bit rusty in my mind...
[23:16] <mwhudson> that also doesn't work :(
[23:18] <gary_poster> mwhudson: sanity checking and optimism: http://pastebin.ubuntu.com/420702/
[23:18] <mwhudson> gary_poster: hmm, is it possible the checkers get reset in tests or something?
[23:19] <gary_poster> mwhudson, they definitely do--see the bottom of checker.py
[23:19] <mwhudson> gary_poster: i don't think my lp_sitecustomize is being executed :/
[23:19] <gary_poster> oh! hm.
[23:19] <gary_poster> uh, ever?
[23:19] <mwhudson> at least not for bin/py
[23:20]  * gary_poster thought he had tests for that
[23:21] <gary_poster> mwhudson, some print statements are working for me in site-customize
[23:21] <gary_poster> mwhudson: younger son is imploding and it is my EoD, need to save wife
[23:22] <mwhudson> gary_poster: ok, i'll fight a bit with this
[23:22] <mwhudson> gary_poster: have a nice evening
[23:23] <gary_poster> mwhudson, will check back later.  this should work, and the various component parts of it are for me.  Sorry to run
[23:23] <mwhudson> somehow it seems not to work for Branch ??
[23:23] <mwhudson> gary_poster: run
[23:28] <mwhudson> gary_poster: ok i know part of the problem, and have a different question (when you're back)
[23:28] <mwhudson> gary_poster: is there a way of saying don't wrap _subclasses_ of a given class?
[23:35] <mwhudson> gary_poster: also, i think import errors from lp_sitecustomize are suppressed somehow
[23:38] <mwhudson> yes, definitely
[23:50] <mwhudson> i think the answer to my subclass question is "no"
[23:53] <bdmurray> not qa-needstesting but qa-done right?
[23:54] <mwhudson> bdmurray: qa-ok
[23:55] <rockstar> sinzui, ping
[23:56] <sinzui> hi rockstar
[23:56] <rockstar> sinzui, so, do you know much about how Launchpad does breadcrumbs?
[23:56] <sinzui> I think I do
[23:56] <rockstar> sinzui, so, with source package recipes, our current breadcrumb says "User >> Branches >> recipe-name"
[23:57] <rockstar> I'd like to modify it to be "User >> Recipes >> recipe-name"
[23:57] <rockstar> So I've modified hierarchy so that I can optionally remove the "Branches" part, but inserting another item in there is proving to be difficult.
[23:57] <sinzui> rockstar, You want to create a BreadCrumb adapter for IRecipe.
[23:58]  * sinzui looks for small example of implementation and test
[23:58] <rockstar> sinzui, well, for ISourcePackageRecipe itself, I'm using the adapter for NameBreadcrumb.
[23:59] <rockstar> And I tried to create a SourcePackageRecipeHierarchy with which I'm (hackily) trying to get another object in the list of things that need breadcrumbs.